Toda semana eu vejo a mesma cena. A agência fechou a estratégia, o cliente confiou, e aí ele pede uma ferramenta de verdade no site: uma calculadora de orçamento, um configurador, um assistente que responde sozinho. A agência topa, manda um preço, e seis semanas depois está pagando do próprio bolso pra terminar. O erro não foi cobrar caro. Foi cobrar no escuro.

Vou ser seco: a margem de uma ferramenta que você revende não vem de achar o dev mais barato. Vem de revender uma entrega previsível que não volta. O barato cobra a diferença depois, em retrabalho e na confiança do seu cliente.

Os números ancoram isso. 78% das agências raramente ou nunca cobram quando o escopo cresce no meio do caminho (Ignition, 2025). O dinheiro vaza antes mesmo de o fornecedor sumir. E quando ele some, sobra pra você explicar pro cliente.

O desconto que você arranca hoje volta como retrabalho amanhã

O reflexo é sempre o mesmo: pra ter margem, a agência caça o dev mais barato. Faz sentido na planilha e quebra na entrega. Porque o preço do dev é só uma parte da conta. O resto, o que não está na proposta, é o que decide se sobrou margem.

(Se o seu time travou antes mesmo de chegar no preço, eu escrevi sobre esse momento exato aqui.)

Pensa no que o barato não inclui. O retrabalho quando a primeira versão volta torta. As três semanas a mais que atrasam a sua entrega e fazem o cliente ligar perguntando. A ferramenta que cai numa segunda-feira de campanha grande, e quem leva a bronca é a SUA marca, não a do freela. O freela cobrou metade. Você pagou o dobro, só que parcelado em dor.

Barato não é preço. É prazo de validade.

“Mas se eu pago mais caro no dev, minha margem some.”

Não. Sua margem some quando a entrega volta. Se você paga 30% a mais por alguém que entrega no prazo, com escopo fechado, e que não te deixa na mão na frente do cliente, você não gastou mais. Você comprou previsibilidade. E previsibilidade é a única coisa que dá pra revender com tranquilidade.

O caro de verdade nunca é a hora do dev. É o custo de oportunidade do projeto atrasado, o custo de refazer o que saiu errado, e o custo de um cliente que parou de confiar. Esses três não aparecem em nenhum orçamento. Mas saem todos do seu bolso.

A conta que ninguém abre: o que faz o preço de uma ferramenta

Aqui está o erro estrutural que vejo direto: a agência precifica ferramenta com a régua de site. Por página, por hora de design, por tela. Só que ferramenta não é site com botão. O que custa numa ferramenta é o que acontece depois que o usuário clica.

Um site mostra. Uma ferramenta faz. E “fazer” é onde mora o custo:

• A lógica de negócio. A regra que calcula, decide, valida. É invisível pro cliente e é a maior parte do trabalho.
• A integração. A ferramenta que conversa com o estoque, o CRM ou o pagamento do cliente custa muito mais que a que vive sozinha.
• O que sustenta depois. Login, dados de usuário, segurança. No dia que a ferramenta guarda informação de gente, o jogo muda de patamar.
• A escala. Aguentar dez pessoas é fácil. Aguentar a ferramenta no ar quando a campanha viraliza é outra história.

Pra dar ordem de grandeza, sem fingir uma precisão que não existe. São faixas de mercado e variam muito por escopo:

O ponto não é decorar a tabela. É entender que duas coisas chamadas “ferramenta” podem ter dez vezes de diferença de custo. Quem precifica as duas igual perde dinheiro numa e perde o cliente na outra.

Como precificar uma ferramenta sem saber quanto vai custar o dev?

Você não chuta. Pede uma faixa fechada antes de fechar com o cliente. Um bom parceiro técnico te entrega o escopo e o preço fixo antes de começar, não uma estimativa que dobra no meio. Com a faixa na mão, você remarca com a sua margem e fecha sabendo exatamente quanto sobra.

É a diferença entre orçamento aberto e escopo fechado. Orçamento aberto é o convite pra surpresa: começa em X, vira 2X, e quem absorve é você. Escopo fechado é o contrário. Você sabe a conta antes de assinar, o seu cliente sabe o que entra e o que fica de fora antes de pagar. Os dois lados dormem tranquilos.

A margem real: você revende previsibilidade, não horas de dev

Agora a virada. Você não está revendendo desenvolvimento. Está revendendo o resultado, com a sua marca na frente, sem o seu cliente nunca saber quem codou. Esse é o modelo white-label, em que o fornecedor entrega na sua marca e fica invisível. E a margem dele não nasce do desconto. Nasce da previsibilidade.

O markup de revenda no white-label costuma ficar entre 40% e 70% sobre o custo da entrega (CloudCampaign). Parece muito até você perceber a condição que quase ninguém diz em voz alta: esse markup só sobrevive se a entrega não voltar. Cada projeto que volta com bug, cada prazo estourado, cada fornecedor que some come essa margem inteira. O markup não é lucro garantido. É lucro condicionado a uma entrega que funciona.

Faz a conta de um caso desses que eu vejo repetir. A agência fecha um configurador pro cliente por R$ 30 mil.

• Caminho A. Acha um freela por R$ 8 mil e comemora a margem gorda. O freela atrasa, a primeira versão não bate com o catálogo, entra retrabalho, e o lançamento que era pra abril vai pra junho. A margem de R$ 22 mil virou prejuízo de reputação.
• Caminho B. Fecha com um parceiro previsível por R$ 15 mil, escopo travado, entrega no prazo. A margem no papel é menor, R$ 15 mil, mas é a margem que de fato ENTRA. E o cliente, satisfeito, volta com o próximo projeto.

Uma agência feliz traz N projetos. Um cliente queimado não traz nenhum.

Desconto é margem que você ainda vai devolver. Previsibilidade é margem que fica.

Qual margem dá pra cobrar revendendo desenvolvimento como agência?

A faixa praticada no white-label vai de 40% a 70% de markup sobre o custo da entrega. Mas o número que importa não é o teto, é o que sobra depois do retrabalho. Markup alto numa entrega que volta dá zero. Markup honesto numa entrega previsível é o que constrói a agência ao longo do tempo.

Previsibilidade é o produto. O resto é sorte.

No fim, o seu cliente não está comprando uma ferramenta de você. Está comprando a tranquilidade de que aquilo vai funcionar quando ele mais precisar. É isso que você revende. A ferramenta é o objeto. A previsibilidade é o produto.

Quando você caça o dev mais barato, não está economizando. Está apostando que dessa vez vai dar certo. Às vezes dá. Mas você não montou uma agência pra viver de aposta.

O barato sempre cobra a diferença. A única pergunta é quando, e na frente de quem.

De uns meses pra cá mudou o perfil de quem me procura. Antes era “tenho uma ideia, faz pra mim”. Agora é “já tenho o app, ele até funciona, mas trava na hora de crescer, e eu não sei se conserto ou jogo fora”. O produto foi vibe coding: gerar software pedindo pra IA e aceitando o resultado sem ler nem entender o código que saiu. Funciona o suficiente pra ter cliente pagando. E o suficiente pra dar medo.

A primeira decisão diante de um desses não é técnica. É de triagem. E a tentação mais cara, a que quase todo mundo tem no primeiro dia, é mandar reescrever tudo do zero. Quase sempre é erro. Na maioria dos casos não é transplante: é suíte de testes primeiro, depois bisturi no que de fato apodreceu. Salva-se muito mais do que o desespero sugere.

Os números explicam o susto e por que ele engana. 45% do código gerado por IA carrega uma falha do OWASP Top 10 (Veracode), e só 10,5% do código vibe-coded passa num review de segurança decente contra 61% que simplesmente “funciona” (Carnegie Mellon). Parece sentença de demolição. Não é. É a medida da distância entre funcionar e aguentar, e distância a gente mede ANTES de demolir, não depois.

Funciona não é o mesmo que pronto. Mas também não é o mesmo que lixo.

Reescrever do zero é o erro mais caro que existe

Todo mundo que me liga com um app travado chega com a mesma sentença na ponta da língua:

“Esse código é uma zona. É mais rápido refazer do zero do que entender essa bagunça.”

Calma lá. Essa frase é o canto da sereia mais caro da engenharia de software, e não fui eu que descobri isso. Joel Spolsky chamou reescrever do zero de “o pior erro estratégico que uma empresa de software pode cometer”, e isso foi em 2000, muito antes de a IA deixar a reescrita ainda mais tentadora e ainda mais cara.

Por que é erro? Porque você está prestes a jogar fora justamente a única coisa que esse MVP provou: que tem gente querendo. O código é feio, mas ele carrega meses de aprendizado embutido. Cada gambiarra esquisita é, na metade das vezes, um caso de borda real que algum cliente encontrou e que a versão “limpa” do zero vai redescobrir do jeito difícil, em produção, de novo.

Pensa no Twitter. Nasceu num monólito Rails porque era o que dois caras conseguiam tocar rápido o bastante pra achar product-market fit. Os problemas de escala vieram depois. Porque deu certo. Se tivessem começado “do jeito certo”, parrudo e distribuído, provavelmente não existiria Twitter pra ter problema de escala. A velocidade do vibe coding é real e é valiosa pra validar. O erro não é ter validado assim. É não trocar de marcha quando a validação acabou.

Reescrita do zero é a vaidade de quem acabou de chegar no projeto.

Antes de tocar em qualquer linha, a suíte de testes

Aqui está o passo que quase todo mundo pula, e é o que separa um resgate de um segundo desastre: você não conserta o que não consegue testar, nem refatora com segurança o que não cobriu antes. Teste não é o último passo do resgate. É o primeiro.

E é exatamente o que o código vibe-coded não tem. A IA gera com um viés brutal de caminho feliz: cobre o fluxo que você descreveu e ignora o resto do universo. Erro de rede, input inválido, dois cliques no mesmo botão, o usuário que faz na ordem errada. Nada disso existe no código, então nada disso quebra de forma visível. Até quebrar na frente do cliente.

“Escrever teste antes de entregar feature nova? Vou ficar duas semanas sem mostrar nada pro board.”

Entendo a ansiedade, e ela está invertida. A suíte de testes não é tempo perdido antes de entregar valor. É o que te dá permissão pra mexer no código sem rezar. Sem ela, cada refactor é uma aposta cega: você arruma um bug e descobre, três dias depois, que quebrou dois outros que ninguém via. Com ela, você refatora de olhos abertos. É a diferença entre operar com luz acesa e operar no escuro.

Na prática, eu nem peço cobertura total de cara. Peço teste nos fluxos que dão dinheiro e nos que perdem dinheiro: o checkout, o login, o que mexe em saldo. É a rede de segurança mínima pra tudo que vem depois ser cirurgia, e não roleta. Essa mesma disciplina de validar antes de confiar a gente já destrinchou em validação local com qualidade real, só que ali aplicada ao fluxo de quem está construindo, não resgatando.

O diagnóstico: lendo o extrato da dívida

Com rede de segurança no lugar, dá pra abrir o capô sem medo. O diagnóstico de um MVP vibe-coded quase sempre encontra os mesmos quatro buracos. Eu chamo de ler o extrato da dívida, porque é literalmente isso: descobrir quanto você deve e pra quem.

• Arquitetura acoplada. A regra de negócio está grudada na infraestrutura, a API foi desenhada sem pensar em carga, o schema não aguenta crescer de lado. Funciona com cinquenta usuários porque tudo funciona com cinquenta usuários. O paper que formalizou isso chama de flow-debt trade-off: a fluidez de gerar código mascara a dívida que cresce em paralelo.
• Observabilidade ausente. Logging, trace e métrica entraram como pensamento tardio, ou não entraram. Quando cai às 3 da manhã, você não tem onde olhar. A frase da OneUptime fica na parede: “observabilidade não é um nice to have, é a sua única rede de segurança”. No código vibe-coded ela é a substituta da revisão humana que nunca aconteceu.
• Segurança de enfeite. Chave de API hardcoded no repositório, autenticação com a lógica invertida, banco exposto sem regra de acesso. Não é exceção: a Apiiro mediu código gerado por IA somando 10x mais achados de segurança em seis meses, com caminhos de escalonamento de privilégio subindo 322%.
• Deploy e CI frágeis. O caso clássico é preview, teste e produção dividindo o mesmo banco. Foi assim que a IA da Replit apagou o banco de produção durante um congelamento de código explícito, em CAIXA ALTA no prompt, e depois mentiu dizendo que o rollback era impossível. A separação de ambientes é a lição mais barata e mais ignorada da lista.

O extrato assusta de propósito. Mas extrato não é despejo. Ele te diz onde está a dívida cara e onde está a dívida que dá pra rolar, e essa distinção é o resgate inteiro.

Como sei se a arquitetura dá pra salvar ou não?

O critério prático é um só: o nível de acoplamento entre a regra de negócio e a infraestrutura, somado a se o modelo de dados aguenta crescer. Se a lógica que importa está enfiada no meio do controller, dependente de um detalhe do banco que não escala de lado, aquele pedaço é reescrita localizada: não tem como salvar a fundação sem refazê-la. Se a regra de negócio está minimamente isolada, mesmo que feia, é remediação: você melhora por dentro sem demolir. A maior parte de um MVP cai no segundo caso. É por isso que reescrita total quase nunca é a resposta certa: você condena o prédio inteiro por causa de dois cômodos.

O que salvar e o que reescrever sem dó

Triagem é decidir o que entra no centro cirúrgico e o que recebe alta. Depois de fazer isso em vários apps, o padrão é bem estável.

Salvar quase sempre: o modelo de domínio que reflete o negócio de verdade (os nomes das coisas e como se ligam), os fluxos que o usuário já validou na prática, e boa parte da interface. Esse é o conhecimento que custou meses e que uma reescrita joga no lixo de graça. A versão dessa disciplina no nível da estrutura do código a gente abriu em seu codebase é o novo prompt: o que decide se escala não é a stack, é o repositório continuar navegável.

Reescrever sem dó: a camada de autenticação e permissão (é onde mais dói deixar errado, porque toca toda requisição), a lógica de negócio que a IA duplicou em oito, dez, doze lugares, o schema que não aguenta tração, e as integrações sem nenhum fallback. A duplicação não é detalhe: em 2024, pela primeira vez na história, código copiado e colado superou código refatorado, com blocos duplicados crescendo 8x (GitClear). Cada cópia é um lugar a mais pra um bug se esconder e nunca ser corrigido em todos.

O que guia o corte é entender por que o app empaca onde empaca. Addy Osmani batizou de 70% problem: a IA leva você rápido a 70%, só que é 70% do volume de código, não 70% do caminho até um produto pronto. Os 30% que faltam são exatamente o que não dá pra gerar no susto: caso de borda, manutenibilidade, performance, segurança. É a parte cara. É a parte que a triagem isola.

Vibe coding serve pra produção?

Serve pra chegar até a porta dela, não pra entrar. Vibe coding é um acelerador de validação espetacular: prova a hipótese, conquista os primeiros clientes, mostra que existe negócio. O erro não é usar. É confundir o protótipo que validou com o produto que escala, e seguir empilhando feature por cima de uma fundação que nunca foi feita pra carregar peso. A própria mecânica disso, de por que o “pede, aceita, deploya” empaca na hora de crescer, a gente discutiu em sair do vibe coding. Vibe coding leva ao MVP. Método leva o MVP a produto.

Estabilizar sem parar o negócio: a cirurgia com o paciente acordado

A última peça, e a que mais diferencia um resgate competente, é o “sem parar o negócio”. Porque o app está no ar, tem cliente usando, tem fatura entrando. Você não pode desligar tudo por dois meses pra arrumar a casa. Tem que operar com o paciente acordado.

O jeito de fazer isso tem nome: padrão Strangler: substituir o sistema velho por fora, módulo a módulo, enquanto ele continua rodando, até o novo estrangular o antigo. Em vez do big bang (“vira a chave do novo num domingo e reza”), você escolhe um pedaço (a autenticação, digamos), constrói a versão nova ao lado, manda uma fração do tráfego pra ela com feature flag, confirma que aguenta, e só então aposenta a velha. Errou? Rollback num clique, ninguém percebe. Repete pro próximo módulo. O risco fica fatiado em pedaços que cabem no bolso, em vez de uma aposta única que pode derrubar a empresa.

E a primeira fatia, quase sempre, é a mais barata e a mais esquecida: separar os ambientes. Banco de produção é sagrado, tem backup automático testado, e ninguém, humano ou IA, encosta nele sem rede. É a correção que teria evitado o desastre da Replit inteiro, e custa um dia.

Tem trade-off, e eu não vendo milagre. No papel, o Strangler é mais lento que reescrever do zero: você mantém dois sistemas vivos ao mesmo tempo por um período, paga o custo de manter os dois falando. É chato. Mas é o preço de não parar de faturar enquanto opera, e é incomparavelmente mais barato que a reescrita que congela o produto por um trimestre e ainda chega atrasada. É o tipo de diagnóstico independente, sem amarra comercial, que a gente entrega numa Auditoria antes de qualquer linha ser tocada: o mapa do que salvar, do que reescrever e em que ordem mexer. O que cortar e o que manter quando se decide o escopo dessa reconstrução a gente abriu em o que cortar e o que manter num MVP.

Funciona não é pronto. Mas também não é lixo.

O instinto diante de um MVP vibe-coded travado é binário: ou ele é maravilhoso porque está no ar, ou é lixo porque o código é feio. Os dois estão errados. Ele é exatamente o que parece: um protótipo que validou um negócio e agora precisa virar produto, com uma dívida que dá pra ler, item por item, e pagar na ordem certa.

A distância entre a demo que encantou e o sistema que aguenta tração é mensurável. Não é fé, é diagnóstico: testes pra acender a luz, o extrato pra saber o que se deve, a triagem pra separar o que salva do que reescreve, e o Strangler pra operar sem desligar o paciente. Quase sempre dá pra fazer sem demolir a casa.

Pronto é um estado que se prova, não que se sente.

A demanda por uma ferramenta de verdade no site do cliente é a melhor receita que uma agência pode ganhar: alta margem, recorrência, mais difícil de você ser trocado. Mas ela esbarra num problema real: você não tem dev, software house pede caro e some, e montar time interno é o jeito mais caro e arriscado de descobrir que dar não daria. A saída é entregar com um parceiro técnico sob a sua marca, sem virar empresa de software. O risco não está em aceitar o projeto. Está em aceitar do jeito errado.

Por que isso é uma oportunidade, não um problema

Quando o cliente pede uma ferramenta (não um site, uma ferramenta que faz algo), ele está dizendo que confia em você para resolver um problema de negócio, não só de imagem. Esse é o tipo de trabalho que paga mais, dura mais e te tira da guerra de preço de landing page. É exatamente onde a agência deixa de ser fornecedora de design e vira parceira de operação.

O problema é que a oportunidade vem embrulhada num medo legítimo: “e se eu aceitar e não conseguir entregar?”. Esse medo é saudável. Ele só não pode virar o motivo de você devolver dinheiro pra concorrência.

As três saídas que parecem óbvias (e onde cada uma quebra)

Recusar, contratar uma software house ou montar time interno são as reações naturais. Todas têm um custo escondido: a primeira te faz perder a conta, a segunda te faz perder margem e controle, a terceira te faz perder dinheiro por meses antes de você saber se valeu. Vale destrinchar.

Recusar a demanda

Parece prudente. Na prática, você ensina o cliente a procurar quem faz “a parte de tecnologia”, e essa pessoa, uma hora, também faz a parte de marketing. Você não só perde o projeto: abre a porta pra perder a conta.

Chamar uma software house

O orçamento volta alto, o prazo volta longo, e o controle sai da sua mão. Pior: na frente do cliente, quem responde pela ferramenta é a sua marca, mas quem decide o ritmo é um fornecedor que você não controla. Quando trava, você está no meio, sem time pra resolver e sem o fornecedor por perto.

Contratar um dev (ou um time)

Essa é a que parece mais “definitiva” e é a mais cara de todas. Um desenvolvedor sênior no Brasil custa entre R$ 12 mil e R$ 20 mil por mês (Glassdoor Brasil), e isso é o salário, sem encargos, sem o tempo até ele produzir, sem o risco de ele sair em seis meses. Você está assumindo um custo fixo alto e recorrente por uma demanda que ainda é pontual. E aí vem a parte que ninguém da agência fala em voz alta: você não sabe contratar dev, não sabe avaliar se ele é bom, e não sabe segurar ele depois. Avaliar um profissional de uma área que não é a sua é uma aposta às cegas com seu próprio dinheiro.

A quarta saída: entregar sob a sua marca, sem virar empresa de software

Existe um meio-termo entre recusar e montar uma área de tecnologia: terceirizar a entrega para um parceiro técnico que trabalha sob a sua marca, com escopo e prazo fechados. Você mantém o cliente, a margem e o relacionamento; o parceiro entrega a ferramenta funcionando, e some do mapa do cliente. É o modelo que o mercado chama de white-label: o parceiro técnico entrega sob a sua marca e não aparece para o seu cliente, e existe justamente porque dev sênior interno é caro demais para a maioria das agências (Xovak).

A diferença entre isso e a software house tradicional não é só preço. É como o trabalho é feito: escopo definido na frente, prazo curto, entrega por fases com você aprovando cada passo. Você não compra “horas de desenvolvimento” sem fim. Você compra um resultado, com data e valor combinados antes de começar.

Onde isso também quebra (porque tudo tem trade-off)

Parceiro errado é tão ruim quanto não ter parceiro. O modelo só funciona se três coisas estiverem claras: o escopo é fechado (sem “depois a gente vê”), o código fica com o cliente (ou com você, nunca refém do fornecedor), e a ferramenta nasce bem-feita, não uma gambiarra barata que trava na frente do cliente final e vira sua dor de cabeça. Ferramenta barata e mal feita é mais cara que software house: você paga duas vezes, e a segunda na frente do seu cliente. Se o parceiro não topa fechar escopo e prazo antes de começar, é o sinal de que você vai virar a software house, só que sem o time.

Como decidir, na prática

Se a demanda é pontual e você quer testar o apetite do cliente sem assumir custo fixo: parceiro, escopo fechado. Se a demanda virou recorrente e previsível a ponto de pagar um salário todo mês com folga: aí, talvez, faça sentido pensar em time, mas só depois de já ter entregue algumas vezes com parceiro e entendido o que esse trabalho exige. Começar pelo time é apostar antes de ter a informação.

A regra simples: não monte estrutura para uma demanda que você ainda não validou. Entregue primeiro, aprenda o custo real, e só então decida se vira operação interna.

FAQ

Quanto custa entregar uma ferramenta dessas via parceiro?

Depende do escopo, mas o ponto do modelo é justamente ter o valor fechado antes de começar, não horas abertas. Uma ferramenta simples (calculadora, formulário inteligente, configurador) costuma sair por uma fração do que uma software house cobra por um projeto “do zero”, porque o escopo é enxuto e o método é padronizado.

O cliente vai saber que terceirizei?

No modelo white-label, não. A entrega sai sob a sua marca. O parceiro técnico não aparece para o seu cliente.

E se a ferramenta der problema depois?

Por isso o “bem-feito” não é luxo, é seguro. Uma ferramenta com boa estrutura é estável e fácil de ajustar. O barulho vem das gambiarras baratas que quebram na frente do cliente final: exatamente o que você quer evitar quando é a sua marca em jogo.

Não seria mais seguro contratar um dev de uma vez?

Só se a demanda já for recorrente o bastante para pagar o salário com folga. Para uma demanda pontual ou ainda incerta, contratar é assumir o custo mais alto e o risco maior (avaliar e segurar alguém de uma área que não é a sua) antes de saber se vale.

Quanto tempo leva?

Ferramentas de escopo fechado costumam ser entregues em semanas, não meses, porque o escopo é definido na frente e o trabalho é feito por fases, com você aprovando cada etapa.

Leia também

• Seu codebase é o novo prompt: o MVP que escala (ou vira lixo)
• Spec-driven development: como sair do vibe coding

Todo founder técnico que senta comigo chega com o mesmo medo: “lanço em semanas, mas não quero reescrever tudo daqui a três meses”. O medo é legítimo. Só que ele faz você cortar a coisa errada.

O MVP que vira lixo quase nunca virou lixo por ter sido rápido. Virou porque cortou a separação (que é barata de manter e cara de refazer) pra manter feature (que é cara de fazer e que quase ninguém vai usar). O MVP que escala faz o inverso: corta feature sem dó e mantém a separação sempre. Ele não nasce protótipo descartável. Nasce como a fase 1 de um produto, e a fase 2 cresce em cima dela quando você cortou e manteve certo.

Os números ancoram a inversão. 42% das startups que morrem morrem construindo algo que o mercado não queria. Num produto médio, 64% a 80% das features são raramente ou nunca usadas. E refazer o que saiu errado é o gasto mais silencioso: times retrabalham cerca de 26% do código antes mesmo de lançar, e a maior parte disso vem de ter entendido errado o que construir, não de ter codado rápido.

Velocidade não é o inimigo do MVP que escala. Escopo cego é.

O MVP não vira lixo por ser rápido. Vira por juntar tudo e manter a feature.

A imagem de MVP que o founder carrega na cabeça é quase sempre a errada: uma versão pequena do produto inteiro. Um pouco de cada coisa. Todas as telas, todas as features, só que meia-boca.

“MVP é pra validar rápido. Faz o mínimo de tudo, capricha depois.”

Esse “mínimo de tudo” é a armadilha. Mínimo não quer dizer raso em tudo. Quer dizer estreito: pouca coisa, inteira. Você escolhe a única coisa que o produto precisa fazer bem pra provar que tem gente querendo, e faz ela do começo ao fim. O resto não é “feito pela metade”. É cortado.

E aqui está o pulo do gato que o medo de retrabalho esconde: separar as coisas é barato, e juntá-las de novo é que custa. Feature é cara de fazer e barata de cortar. Quando você corta arquitetura pra ganhar tempo, economizou no que era barato e vai pagar caro depois. Quando você corta feature, economizou no que era caro e que provavelmente ninguém ia usar.

MVP que vira lixo cortou no lugar errado.

O que cortar sem dó

Cortar bem é uma habilidade, e dói porque tudo parece essencial no começo. Não é. Comece por aqui:

• Features que não validam a tese. Esse é o corte-mãe. Se a feature não serve pra provar que alguém quer o produto, ela não é v1. Os 42% que morrem construíram algo sem product-market fit: a evidência de que existe gente o suficiente querendo o que você faz, no preço que você cobra. Não morreram por falta de feature. Morreram de feature na direção errada.
• A segunda, a terceira e a quarta feature. Num produto médio, só 12% das features geram 80% do uso. No MVP você ainda não sabe qual é essa fatia. Mas sabe que não são as vinte. Aposta em uma, no máximo duas.
• Escala que não existe. Cache, fila, sharding, microservice pra dez usuários. Otimizar uma carga que você não tem é resolver um problema imaginário enquanto o problema real (alguém usar) segue sem resposta.
• Configurabilidade. Todo “e se o cliente quiser mudar isso?” vira um painel de settings que dobra o escopo. No MVP, deixa fixo no código. Configurável é problema de quem já tem cliente.
• Polish. Animação, dark mode, onboarding de cinco passos, tela vazia ilustrada. Tudo real, tudo fase 2.

O que sobra parece pouco. É pra parecer. Se o seu MVP não te deixa um pouco constrangido, você cortou de MENOS.

O que manter sempre (manter a separação é barato; refazê-la é que custa)

Cortar feature é a parte fácil depois que a ficha cai. Onde eu vejo o founder com pressa errar é no outro lado: o que NÃO se corta, nem no prazo mais apertado. São poucas coisas, todas baratas de deixar certas agora e caríssimas de refazer depois.

• O modelo de domínio. Os nomes das coisas e como elas se ligam. Trocar “usuário” por “conta” e “organização” no mês seis é migração de dados, refactor que cruza o sistema inteiro e bug em produção. Decidir isso na semana 1 custa uma conversa.
• As divisões entre capacidades de negócio. Onde o pagamento termina e o pedido começa. Você não precisa implementar os dois bem. Precisa saber onde fica a linha entre eles, pra depois mexer num sem desmontar o outro.
• Identidade e quem-pode-o-quê. Se o produto tem mais de um tipo de usuário, enfiar auth e permissão depois é um dos refactors mais caros que existem, porque toca toda requisição.
• Um fio de observabilidade. Log estruturado e um jeito de saber o que quebrou. Não é feature. É o que te deixa dormir.

O número que justifica a teimosia: times retrabalham perto de 26% do código antes do release, e a Carnegie Mellon aponta a mesma causa raiz há décadas. Mais da metade do retrabalho nasce de requisito mal entendido, não de código mal escrito. O retrabalho caro não vem de você ter codado rápido. Vem de ter traçado a separação no lugar errado, ou de não ter traçado nenhuma.

Como manter a separação pro que eu nem sei se vai escalar?

Você não adivinha o que vai escalar, ninguém adivinha. Mas não precisa: em vez de decidir a implementação, você decide onde ficam as costuras. Manter a costura é barato (um módulo com nome claro, o pagamento que não está enfiado no meio do pedido) e atrás dela você faz o mais simples e burro que funciona hoje. Quando a carga aparecer, se aparecer, você troca o que está atrás sem mexer em quem depende dela. A fase 2 vira troca de peça, não recomeço.

A versão dessa disciplina no nível do código (organizar por feature, front e back no mesmo repositório, decisão registrada) a gente destrinchou em seu codebase é o novo prompt, que é o que mantém um agente de IA produtivo no seu MVP seis meses depois. E o registro do porquê de cada decisão dessas mora nos ADRs. Este post é o andar de cima: o que cortar e o que manter antes de o código existir.

MVP é a fase 1, não o protótipo (a fase 2 é a prova)

Tem uma palavra que denuncia que o MVP virou lixo: reescrita. Joel Spolsky chamou reescrever do zero de “o pior erro estratégico que uma empresa de software pode cometer”, e isso foi em 2000, muito antes de a IA deixar a reescrita ainda mais tentadora e mais cara. O MVP que escala nunca passa por ela. Passa por extensões: cada fase soma em cima da anterior, porque a anterior deixou a separação no lugar.

É o que a gente faz na Nextside num Sprint: escopo fechado, time sênior, um MVP funcional em 4 semanas que já nasce com as divisões certas pra crescer por fases. A pressa fica no escopo, o rigor fica na separação. E o prazo curto não é limitação, é o mecanismo: ele força a conversa de corte que o founder adia por meses.

O MVP que escala é o que você não precisa refazer

A diferença entre o MVP que escala e o que vira lixo não está na stack, no tamanho do código nem no nome da arquitetura. Está em duas decisões que você toma antes de escrever a primeira linha: o que cortar e o que manter.

Corta a feature, a escala que não existe, o polish, o “e se”. Mantém o domínio, as divisões, a identidade. Faz pouca coisa inteira em vez de muita coisa pela metade, e a fase 2 vira uma extensão do que você já tem, não o velório do que jogou fora.

MVP que escala não é o que ficou pronto mais rápido. É o que você não vai precisar refazer.

Seu codebase é o novo prompt. Num MVP feito com agente de IA, o que decide se ele escala por fases ou vira lixo descartável não é a stack que você escolheu. É se o agente ainda consegue se localizar no seu repositório daqui a seis meses. E isso você resolve na organização: código por feature, front e back no mesmo monorepo, decisões registradas em ADR. Não na esperteza do prompt.

O número que ancora isso: num estudo de trajetórias de coding agent em bugs reais, as tentativas que resolveram o problema mexeram no mesmo arquivo do patch correto em 93,6% das vezes. As que falharam, 62,7%. Localizar o código certo é metade do jogo, e localizável é uma propriedade da sua arquitetura, não do modelo.

Arquitetura parou de ser o imposto que você paga pra ir devagar. Virou o que mantém a IA rápida.

O lixo não é o que foi feito rápido. É o que foi feito cego.

Todo founder técnico que me procura chega com o mesmo medo, e ele é legítimo: “preciso lançar em semanas, mas não quero reescrever tudo daqui a três meses”. Daí vem a crença que eu quero matar aqui:

“Arquitetura é luxo de quem tem tempo. Lança logo, arruma depois.”

Eu ouço isso toda semana. E concordava em certo nível, até a IA mudar a conta. Porque “arruma depois” pressupõe uma escolha que não existe mais: ou você lança rápido, ou entrega bem-arquitetado. Aceitar essa escolha é aceitar que o MVP nasce protótipo descartável, e que a versão “de verdade” vem depois, do zero.

Calma lá. Essa dicotomia morreu, e quem matou foi a própria IA.

Antes, arquitetura boa custava tempo. Você desenhava boundaries, separava responsabilidade, escrevia doc. Cada hora disso era uma hora que não virava feature na tela. Num MVP com prazo de semanas, cortar arquitetura parecia o trade-off racional. Era. Não é mais.

O que mudou: o código que você gera hoje, na maior parte, não sai mais da sua cabeça direto pro editor. Sai de um coding agent: um agente de IA que lê, edita e roda seu repositório por conta própria, operando dentro de um harness, a plataforma que pluga o modelo nas ferramentas de código. Claude Code e Cursor são dois harnesses. E esse agente tem uma característica que muda o cálculo inteiro: ele é tão rápido quanto seu repositório deixa ele ser.

O vibe coding (o tal “pede, aceita, deploya” sem entender o que saiu) é ótimo pra protótipo de fim de semana. O problema é a conta, que não é linear. Um paper de 2025 formalizou isso como flow-debt trade-off: a fluidez de gerar código mascara a dívida que se acumula em paralelo. Inconsistência arquitetural, dependência que ninguém avaliou, o mesmo problema resolvido de cinco jeitos diferentes. Lá pelo sexto mês, o custo de desfazer a dívida passa o valor do que foi construído.

Vira uma bola de ferro. E o detalhe cruel: a bola de ferro não trava só o seu time. Trava o próprio agente que a criou. Os sinais de que ele depende pra se achar (nome consistente, padrão previsível, baixo acoplamento) foram destruídos pela própria geração descuidada.

MVP que vira lixo não é o que foi feito rápido. É o que foi feito CEGO, sem deixar pista nem pra IA nem pro humano que vai mexer nele depois.

A IA lê seu repositório, não seu prompt

Tem uma frase do Matt Pocock que resume a virada: “seu codebase, não seu prompt, decide a qualidade do output da IA”. Soa exagero. Não é.

Veja como o Claude Code acha código num repositório grande. Ele não usa busca semântica, não tem um índice mágico de embeddings. Ele faz o que um dev sênior faria: navega o filesystem, lê arquivo, e roda grep, a velha busca literal por texto do terminal, pra achar exatamente o que precisa. A Anthropic escolheu grep de propósito: embedding fica stale, o repo muda toda hora, e índice velho mente.

A consequência é física, não filosófica: grep acha string, não intenção. “grep finds strings, not intent.” Se a função que importa se chama validateToken, o agente acha de primeira. Se a lógica está espalhada em cinco arquivos frouxamente ligados por import, com nome genérico tipo handler ou process, ele vasculha, carrega arquivo demais, e queima contexto antes de começar o trabalho.

E aqui mora o número que abre esse post. Pesquisadores olharam trajetórias de coding agent em bugs reais do SWE-bench. As tentativas que consertaram o bug mexeram no mesmo arquivo do patch correto em 93,6% dos casos. As que falharam, 62,7%. Traduzindo: o gargalo do agente quase nunca é “saber programar”. É achar o trecho certo. Localizar bem é o que separa o PR que mergeia do que apodrece.

Organização por camada técnica sabota exatamente isso. Quando tudo é controllers/, services/, models/, pra mexer no checkout o agente abre cinco pastas e carrega arquivo de outras doze features que moram nas mesmas pastas. A janela de contexto vira, na frase de um artigo que li sobre isso, “a junkyard of irrelevant stuff”, um ferro-velho de coisa que não importa.

E não é só a IA que sofre. Camada técnica é a velha violação do SRP, o primeiro princípio do SOLID, que o Uncle Bob redefiniu como “junte o que muda pela mesma razão, separe o que muda por razões diferentes”. A organização por camada faz o oposto: estilhaça a feature (que muda junta) por quatro pastas, e amontoa em cada pasta código que só tem em comum o fato de ser “um controller”. A correção tem nome, e é o assunto da próxima seção.

A IA não devia ser esperta o bastante pra achar sozinha?

É a pergunta que todo CTO faz, e a resposta honesta é: ela é, até certo ponto, e isso piora a sua complacência. O agente acha, sim. Lê 25 arquivos pra responder sobre 3 funções, porque sem estrutura ele não sabia quais 3 eram. Funciona, e te cobra em tokens, em tempo, e em alucinação quando o contexto enche de ruído.

E aqui eu preciso ser honesto, porque a versão simplista dessa ideia (“codebase ruim trava a IA”) é exagerada. Não é que humano e agente travem igual. Eles têm forças opostas. A IA aguenta vasculhar um repo caótico na força bruta: regra de negócio espalhada em vinte arquivos, ela queima um milhão de tokens de contexto e acha mesmo assim. Um humano, no mesmo repo, levaria dias, ou desistiria. Nesse caso a IA é melhor que você.

Só que o humano tem uma arma que a IA não tem nativamente: o IDE. Você lança um evento com ApplicationEventPublisher no Spring, e o IntelliJ te mostra cada @EventListener que escuta aquele evento, em ordem, num clique. É um índice semântico do código inteiro, de graça. A IA não tem isso: ela cai em vários greps e em carregar arquivo atrás de arquivo no contexto, e é aí que bate o context rot, a degradação de qualidade do modelo conforme a janela enche.

Então a frase certa não é “a IA expõe arquitetura ruim”. É: arquitetura ruim cobra um pedágio diferente de cada um. Do humano, em tempo e em dependência de IDE. Da IA, em tokens e em context rot. Repo organizado baixa o pedágio pros dois ao mesmo tempo. É por isso que o codebase é o novo prompt: ele é, literalmente, o contexto que o agente lê antes de cada tarefa, e quanto mais limpo, menos ele paga pra te entender.

Organize por feature, não por camada (e esqueça o nome da arquitetura)

A correção é mais chata do que parece, e é de graça: organize o código por feature, não por camada técnica.

Em vez de controllers/, services/, repositories/ (onde cada feature está estilhaçada em quatro pastas), você faz uma pasta por capacidade de negócio: orders/, payments/, refunds/, cada uma com o seu controller, serviço e acesso a dados dentro. O nome disso, na literatura, é vertical slice: uma fatia que vai da borda (a request) até o fundo (o banco), inteira, no mesmo lugar. Jimmy Bogard cravou a regra de ouro: “minimize coupling between slices, and maximize coupling in a slice”. Acoplamento mínimo entre fatias, máximo dentro de uma.

Pra IA, isso é roteamento de atenção. O agente lê o nome da pasta antes de abrir qualquer arquivo, e infere o escopo da tarefa na hora. “Mexe no refund” já o leva pra refunds/, e tudo que importa está colocado ali junto. Uncle Bob chamou isso de Screaming Architecture há mais de dez anos: a estrutura de pastas deve gritar o que o sistema faz, não qual framework ele usa. Em 2011 era estética. Hoje é performance de quem vai codar. E quem vai codar é um agente.

Aqui cabe uma honestidade que desarma. No briefing desse post, alguém da equipe escreveu “usem a arquitetura NGC ou a que for”. Fui pesquisar o que é “arquitetura NGC”. Não existe. Não é um padrão consolidado; é provável typo de N-tier, ou só uma sigla que escapou. E sabe o que isso prova? Que o nome importa menos do que você acha. Clean, hexagonal, onion, N-tier: no fundo são a mesma ideia (regra de negócio no centro, framework e banco na borda) com vocabulário diferente. O que decide se o agente, e o seu time, vai conseguir evoluir o código não é o crachá da arquitetura. É a disciplina de fronteira.

Dito isso, não caia no extremo oposto. Clean Architecture com quatro camadas de abstração num MVP é over-engineering; alguém comparou a jogar Dark Souls: regra demais, cerimônia demais, pra um produto que talvez ninguém queira ainda. O ponto não é a arquitetura mais pura. É a mais navegável.

E tem trade-off, claro. Organizar por feature gera duplicação: duas fatias validam parecido, três features batem na mesma tabela. O instinto é abstrair tudo num shared/, e aí o shared/ vira a lixeira que acopla todo mundo de novo. Sandi Metz tem a melhor regra pra isso: “duplication is far cheaper than the wrong abstraction”. Duplicação é mais barata que a abstração errada. Num MVP, topar um pouco de cópia pra manter as fatias independentes quase sempre vale mais do que o DRY religioso. Shared só pra infra de verdade: cliente de banco, log, auth. Nunca pra regra de negócio.

Monorepo e ADR: pare de fazer a IA (e seu time) adivinhar

Organizar dentro do projeto resolve metade. A outra metade é o que está entre os projetos, e é onde o monorepo entra.

A ideia: front e back no mesmo repositório. Junto com a pasta de documentação, os ADRs, as convenções. Um histórico só. Tem uma frase do Francis Dortort que fecha o argumento: “a repository boundary is a context wall. Every wall degrades the quality of AI-generated output”. Toda fronteira de repositório é uma parede de contexto, e toda parede degrada o que a IA produz.

Pensa no caso concreto. Você pede “adiciona um campo no cadastro”. Num setup de dois repos separados, o agente precisa de duas conversas sem memória uma da outra, e o contrato entre front e back deriva no meio do caminho. Num monorepo, é uma transação só: ele renomeia o campo no banco, atualiza a API, ajusta a UI e o teste, num único contexto, num único commit. DB, API e UI sem trocar de janela. É exatamente o tipo de mudança cross-cutting que um MVP faz o tempo todo.

Ferramenta? Comece simples: pnpm workspaces com Turborepo resolve a maioria dos MVPs com baixíssima fricção. Nx quando a dor de escala aparecer, não antes. E o trade-off honesto: monorepo sem tooling de build seletivo te dá CI lento. Se cada commit rebuilda tudo, a conta explode. É um problema solucionável, mas é um problema que você assume de propósito.

O ADR é a outra peça, e a mais subestimada. ADR eu já expliquei em outro post: registro curto e datado de uma decisão técnica e do porquê dela. O que mudou com a IA é o uso. Sem os ADRs no contexto, o agente fica, na frase de um artigo, “deprived of architectural intent”: ele vê a implementação, mas não o raciocínio. Ele sabe que você usa Postgres. Não sabe por que você descartou Mongo, então pode “melhorar” seu código reintroduzindo exatamente o que você rejeitou. O ADR, junto com um CLAUDE.md ou AGENTS.md no repo, é como você entrega a intenção de mão beijada, em vez de rezar pra ele adivinhar.

Agora o contrapeso, porque eu não vendo milagre. Nada disso é mágica, e mais documento não é sempre melhor. Um estudo da ETH Zurich testou arquivos de contexto e achou que AGENTS.md gerado automaticamente PIOROU a taxa de acerto em vários cenários e subiu o custo de inferência em mais de 20%. A própria METR mediu devs sêniores experientes ficando 19% mais lentos com IA num estudo controlado, achando, eles mesmos, que estavam mais rápidos.

O que isso te diz: o ganho não vem de encher o repo de markdown. Vem do não-óbvio bem registrado: a decisão contraintuitiva, o gotcha que não dá pra inferir do código. ADR e convenção são bisturi, não enchente. Bom contexto, nas palavras da própria Anthropic, é “the smallest possible set of high-signal tokens”, o menor conjunto de tokens de alto sinal, não o maior monte de tokens.

O MVP que escala é o que a IA ainda entende amanhã

Junta tudo e o retrato é simples. O MVP que escala não tem stack mais cara nem arquitetura mais sofisticada que o MVP que vira lixo. Tem fronteira. Código por feature, front e back no mesmo lugar, decisão registrada. Três disciplinas baratas que, somadas, mantêm um agente de IA produtivo na fase 2, na fase 3, na fase 4, em vez de travado no mês seis.

Isso não quer dizer construir tudo. Quer dizer cortar a coisa certa, e o que cortar e o que manter num MVP virou um post só. Martin Fowler tem um quadrante de dívida técnica que todo founder devia conhecer: dívida pode ser deliberada e prudente (“a gente precisa lançar agora e lida com a consequência depois”) ou imprudente e cega (“não temos tempo pra design”). A primeira é uma decisão de negócio legítima. A segunda é o protótipo que vai explodir. O lixo não é ter dívida. É não saber que você tem.

E o que cortar primeiro? Escala prematura. O Startup Genome olhou mais de três mil startups e achou que 74% das que morreram, morreram por escalar antes da hora: otimização, microservices, infra distribuída pra uma carga que não existia. Microservices num MVP é o exemplo perfeito de dívida imprudente disfarçada de boa engenharia. Comece monólito, modular, com fronteira limpa. A fronteira é o que torna a fase seguinte uma extração, não uma demolição.

Foi o mesmo padrão sobre o qual escrevi quando code review virou o gargalo: a IA acelerou o indivíduo, e a parte que não acompanhou virou o freio. Com arquitetura é igual, só que antes: o repositório desorganizado é o gargalo que você planta no dia um e só sente no dia cento e oitenta.

Seu MVP não precisa ser perfeito pra escalar. Precisa ser legível. O código que a IA ainda entende daqui a seis meses é o código que não vira lixo. O resto é reescrita esperando a data.

Você prototipou rápido com IA. Agora o app não escala, e cada feature nova quebra duas antigas. Esse é o ponto exato onde o vibe coding para de ajudar, e onde o spec-driven development (SDD) começa a pagar. A ideia é simples e inverte a ordem do jogo: a especificação vira o artefato principal, e o agente implementa a partir dela em vez de adivinhar. O trade-off é real: você troca a euforia do “deu certo de primeira” por 30 minutos escrevendo spec antes de codar. Pra protótipo descartável, não compensa. Pra o que vai pra produção e precisa crescer, é o que separa entrega de gambiarra.

Vibe coding é ótimo pra descobrir o quê construir. É péssimo pra sustentar o que já existe.

O vibe coding não falha por ser IA. Falha por ser ambíguo.

Num prompt solto, o modelo tem 30 formas de implementar a mesma feature, e roda a mesma instrução duas vezes, sai diferente. Essa ambiguidade é tolerável no protótipo e fatal na manutenção: ninguém (nem você, nem o próximo dev, nem o agente) sabe qual era a regra. O código é a única fonte de verdade, e ela muda a cada geração.

Se você é CTO e ainda está no vibe coding, o sintoma é familiar: o MVP saiu numa semana, o time dobrou a velocidade no começo, e agora cada PR de IA precisa de três rodadas de review porque o agente “esqueceu” uma decisão que nunca foi escrita em lugar nenhum. Vi isso de perto mais de uma vez: o pessoal acha que é questão de contratar mais um sênior. Não é.

O gargalo deixou de ser escrever código. Virou alinhar contexto.

O que muda no spec-driven development

SDD coloca a especificação antes da geração de código: requisitos, regras de negócio, contratos de API e restrições de arquitetura viram um documento que o agente lê e segue. A spec é versionada, revisada e reusada: o código passa a ser saída, não a fonte de verdade. Menos adivinhação, menos loop de “não era isso”.

Na prática o fluxo é direto: você descreve o comportamento e as restrições → o agente propõe um plano contra a spec → você valida o plano (não 400 linhas de diff) → o agente implementa e testa contra os critérios que a própria spec definiu. O review deixa de ser “isso está certo?” e vira “isso bate com a spec?”. Uma pergunta que dá pra responder em minutos.

Não é teoria de blog. Em projetos internos com o Spec Kit, o GitHub relata cerca de uma ordem de grandeza menos ciclos de “regerar do zero” que prompting ad-hoc. A AWS documenta com o Kiro casos de features de 40 horas entregues em menos de 8 horas de tempo humano quando o trabalho começou pela spec. E o próprio criador do termo “vibe coding”, Andrej Karpathy, já reconheceu publicamente o limite da abordagem pra software de verdade.

SDD funciona com agentes de IA como Claude e Copilot?

Sim, e é exatamente pra isso que foi feito. Ferramentas como GitHub Spec Kit e AWS Kiro integram com agentes como Claude Code, Copilot e Gemini CLI. A spec vira o contexto que o agente segue: o mesmo papel que um CLAUDE.md bem escrito cumpre no dia a dia, só que elevado a artefato de primeira classe do projeto.

Onde isso quebra

SDD não é bala de prata, e fingir que é seria cair no mesmo erro do hype do vibe coding.

“Isso é só mais cerimônia. Mais um documento bonito que ninguém vai ler.”

Pode ser. Esse é o risco real, e eu já vi virar isso. Escrever spec custa tempo de cabeça: pra um spike de um dia, um teste de hipótese ou um throwaway, o overhead não se paga, vibe coding ganha. SDD também é tão bom quanto a spec: spec vaga gera código vago, e você só transferiu a ambiguidade pra um documento mais bonito.

A régua que uso é simples: se o código vai sobreviver mais de um mês ou passar pela mão de outra pessoa, especifique. Se é pra jogar fora, não. A decisão é por estágio, não por dogma.

Spec-driven development substitui o vibe coding?

Não pra tudo. Vibe coding continua ótimo pra protótipos, spikes e validação de hipótese, onde a velocidade de descobrir vale mais que a disciplina de sustentar. SDD ganha quando o código vai pra produção, precisa escalar ou passar pela mão de outras pessoas. Não é um substituindo o outro. É saber em que estágio você está.

Como sair do vibe coding sem parar o time

Não precisa reescrever tudo. A migração é incremental e começa na próxima feature, não num big bang:

• Escreva a spec antes de chamar o agente, mesmo que curta. Comportamento esperado, regras e restrições. Cinco linhas já mudam o jogo.
• Toda regra de negócio mora na spec: não num comentário, não no Slack, não na cabeça de alguém. Se não está na spec, não existe pro agente.
• Use a spec como critério de review: a pergunta deixa de ser “isso está bom?” e vira “isso bate com o que a gente especificou?”.

Em poucas semanas o retrabalho cai, porque o contexto parou de evaporar entre uma geração e outra.

SDD deixa o desenvolvimento mais lento?

No começo de cada feature, sim, você investe os tais 30 minutos escrevendo a spec. No total, costuma ser mais rápido: é a diferença entre a ordem de grandeza menos ciclos de regerar do zero que o GitHub relata e as features de 40h entregues em menos de 8h que a AWS reporta. Você paga adiantado pra não pagar o juro composto do retrabalho depois.

A spec é o contexto que não evapora

Vibe coding te dá o primeiro quilômetro de graça e cobra o resto da estrada em retrabalho. SDD faz o oposto: cobra adiantado e devolve previsibilidade.

O ponto não é abandonar a IA: é parar de tratar o código gerado como fonte de verdade. A fonte de verdade é a spec. O código é só a saída.

Se a sua equipe vai gastar IA de qualquer jeito, gaste no que está especificado.

Spec-Driven Development resolveu um problema real: você externaliza a intenção em markdown versionado (PRD, tech spec, lista de tasks) e a spec vira a fonte da verdade. Só que ninguém te conta a conta da execução. Uma spec gera dezenas de tasks, e rodar tudo numa conversa só é onde o contexto degrada e você vira gerente de janela. A saída que a indústria inteira convergiu, de framework caro a while loop de bash, é a mesma: tirar o estado da janela do modelo e botar em arquivo ou código, com um revisor que nunca é quem escreveu. Os Dynamic Workflows da Anthropic, onde o próprio Claude escreve o script que orquestra os agentes, são uma forma disso. Tem várias.

Esse post é sobre por que a execução era o gargalo o tempo todo, e por que todo mundo está chegando nas mesmas duas regras.

Ninguém te conta a conta da execução

Spec-Driven Development é simples de descrever: você escreve a intenção antes do código. PRD vira tech spec, tech spec vira lista de tasks atômicas, e só então o agente gera código. GitHub Spec Kit, Amazon Kiro, Tessl, cada um com seu sabor. A spec é a fonte da verdade, o código é consequência.

Escrever a spec é a parte fácil.

Minha última spec gerou trinta e poucas tasks. O inferno não começou ali. Começou na hora de executar as trinta e poucas numa conversa só. Você roda task atrás de task, a janela enche, e lá pela vigésima o agente já esqueceu a decisão que ele mesmo tomou na quarta.

Isso tem nome e foi medido. Context rot, a queda de qualidade do modelo conforme o contexto cresce, foi testado pela Chroma em 18 modelos. Os 18 degradaram, e a degradação começa bem antes da janela encher. O paper “Lost in the Middle” já tinha mostrado a mesma curva: o modelo perde a informação enterrada no meio de um contexto longo.

O remendo que a comunidade adotou é abrir uma janela limpa por task: contexto novo, recola a spec, aponta a task, executa, repete. Funciona contra o rot. E te transforma em estagiário de copy-paste, trinta e poucas vezes.

A spec era a parte fácil.

As três fases de quem carrega o contexto

O gargalo sempre foi o mesmo: alguém precisa segurar o estado e consolidar os resultados enquanto as tasks rodam. O que mudou foi quem carrega esse peso.

Fase 1, na mão. Você é a janela de contexto. Roda task por task, dá /clear, relê a spec, segura o estado na cabeça e na conversa. Vai bem pra cinco tasks. Na trigésima, você já é o gargalo.

Fase 2, delegando. Você joga a execução pros subagentes. Ajuda. Só que o output de todos volta pra mesma janela, a do agente principal que você está dirigindo, e é essa janela que vira o consolidador e apodrece. Agent Teams melhoraram com uma task list compartilhada, mas o lead ainda dirige passo a passo. O gargalo mudou de lugar, não sumiu.

Fase 3, workflow. Aqui muda a física. O plano sai do seu contexto e vira código. Um script segura o loop e os resultados intermediários, e o contexto do modelo só vê a resposta final. Cada task roda numa janela isolada. Foi aqui que eu finalmente parei de ser o gargalo. É o que os Dynamic Workflows do Claude Code fazem: o próprio Claude escreve um script JavaScript de orquestração, e um runtime executa em segundo plano, com até 16 agentes simultâneos e teto de mil por run.

Jarred Sumner, criador do Bun, levou isso ao extremo. Portou o Bun de Zig pra Rust exatamente nesse esquema: tasks em paralelo, dois revisores contestando cada arquivo. Setecentas e cinquenta mil linhas de Rust, 99,8% da suíte de testes passando, onze dias do primeiro commit ao merge. Ainda não foi pra produção, é demonstração de capacidade. Mas o número é esse.

Por que o revisor não pode ser quem escreveu?

Porque o modelo tem viés de auto-preferência. Self-preferential bias é a tendência do modelo de defender o próprio output quando ele mesmo é o juiz. Um corretor que escreveu a prova é um corretor suspeito.

O jeito de matar isso é estrutural. O revisor roda como um agente separado, com contexto próprio, às vezes num modelo diferente, com a única missão de tentar derrubar o resultado antes dele ser aceito. No workflow você bota um verificador adversarial por output. No fim, os próprios agentes abrem os PRs. Quem produz NUNCA é quem aprova.

Custa caro, e o ROI é de nicho

Vou ser honesto, porque a parte que ninguém posta é o custo. Dynamic Workflows é research preview e queima token sem dó. Tem relato de gente torrando o limite de cinco horas em dezoito minutos, e de runs de três milhões de tokens sem um aviso de custo no meio. Não é escala de graça.

Então pra quem isso paga?

Pra quem tem senioridade pra revisar. A alavanca do sênior é julgamento: saber quando a IA cuspiu slop, corrigir rota, barrar a task ruim. Júnior na mesma ferramenta é dinheiro no ralo, porque sem engenharia de software de verdade ele aceita o que vier e bate cabeça no resultado final. O ROI anda colado na senioridade, não na ferramenta.

Isso vira default no dia que rodar trinta tasks em paralelo, cada uma com seu revisor, custar o mesmo que rodar uma na mão. Quem quer antecipar esse dia já faz o token doer menos com roteamento de modelo: a maior parte das tasks num modelo barato, o caro só no plano e no review.

Ferramenta muda, a física é a mesma

A parte mais interessante não é nenhuma ferramenta específica. É que todo mundo, partindo de lugares diferentes, está chegando nas mesmas duas regras.

Regra um: a memória do projeto vive nos arquivos, não no contexto. ADR no repo, project-context.md, state.json, todo.md, matriz de decisão versionada. O agente não precisa “lembrar” da decisão da task quatro. Ele lê o arquivo. O context rot some porque você parou de empilhar histórico na janela.

Regra dois: o revisor nunca é o autor, por construção. Contextos separados pra quem gera e pra quem valida. O validador entra assumindo que tem bug e vai caçar.

Olha o tanto de gente que chegou nisso por caminhos opostos:

• Ralph loop (Geoffrey Huntley): embrulha o agente num while, contexto limpo a cada volta, memória no disco. Monolítico de propósito. Ele rejeita multi-agente, e ainda assim externaliza o estado igualzinho.
• Dynamic Workflows (Anthropic): o oposto do Ralph, fan-out de centenas de agentes, mas o script segura o estado e o revisor adversarial é separado.
• BMAD, MDDD, cstk: frameworks da comunidade que, cada um do seu jeito (ADR mais reviewer adversarial, matriz de decisão, ondas com state.json e roteamento de modelo), implementam as mesmas duas regras.

“Vocês tão só reinventando um while loop com mais etapas.”

Em parte, sim. O Ralph loop é a forma mais crua disso, e funciona. A diferença é o que você pendura em cima: consolidador, revisor separado, roteamento de modelo, tudo codificado num harness em vez de no seu prompt de três da manhã. O princípio é velho. A disciplina de aplicá-lo é o que muda o resultado.

O trabalho que você achava que era pensar

Spec-Driven Development não falhou. Ele resolveu a parte que dava pra resolver escrevendo, e expôs a parte que faltava: executar sem o contexto apodrecer e sem você no meio do circuito copiando output de um lado pro outro.

A saída não é uma ferramenta. É uma física: estado fora da janela, revisor fora do autor. Dynamic Workflows, Ralph loop, cstk, BMAD, são sotaques da mesma frase.

O trabalho que você achava que era pensar sempre foi gerenciar contexto. A IA não mudou isso. Só deixou na cara.

O Claude Code já navega seu site sozinho via Playwright: clica, preenche, valida regressão. Pra app mobile dá pra fazer a mesma coisa, mas ninguém explica direito como. Fui atrás. A resposta é o Maestro, um framework open source de teste E2E mobile com flows escritos em YAML, plugado no Claude Code. Um único arquivo de teste roda igual em iOS e Android, sobre o binário compilado, sem instrumentar o app. React Native, nativo ou Flutter, tanto faz. O Claude inspeciona a tela, escreve o flow, roda e conserta o que quebra. E não: o caminho certo NÃO é “dar acesso à tela pro Claude”. Screenshot por coordenada é o último recurso, não o primeiro.

Esse post é o setup que montei pra fechar no mobile o buraco que o Playwright já fechou pra web. Aqui na Nextside ainda não virou pipeline de produção. É o caminho que estou adotando, com a engenharia destrinchada, os comandos na mão e os números de quem já trilhou ele.

Não é “dar acesso à tela”. É ler a árvore.

Quando eu conto isso, vem sempre a mesma pergunta, e eu também fiz ela no começo: “o Claude não consegue só olhar a tela e clicar, igual um humano?”. Consegue. Chama Computer Use: o Claude controla a interface por screenshot e clique em coordenada de pixel. Lançou no Claude Code em março de 2026, dirige o simulador, funciona pra demo.

Só que é o jeito errado pra teste.

O Playwright que você já usa nunca olhou pixel nenhum. Ele lê o accessibility tree, a árvore estruturada que descreve “botão rotulado Entrar, aqui”. Age por elemento, não por coordenada. É por isso que é rápido e não alucina onde clicar.

A diferença dá pra medir em token: a árvore de acessibilidade de uma tela sai por uns 10 tokens, e um screenshot da mesma tela custa de 1.600 a 6.300. Multiplica por cada passo de um teste de vinte telas e você entende por que visão não escala num loop de QA.

No fundo são três jeitos de fazer o Claude mexer no app, do melhor pro pior:

• MCP ou CLI lendo a árvore. Estruturado, determinístico, barato em token. É o “jeito Playwright”, e é onde o Maestro vive.
• Computer Use por screenshot. O Claude enxerga a tela e chuta coordenada. Generaliza pra qualquer app, mas é lento (2 a 5 segundos por ação), erra clique e queima contexto.
• Nada. Você testando tudo na mão, que é de onde a gente tá saindo.

A própria Anthropic ordena assim. A hierarquia de ferramentas do Claude Code é MCP primeiro, depois shell, depois Chrome, e só cai pro controle de tela quando nada mais alcança: “apps nativos, simuladores e ferramentas sem API”.

Screenshot é o último recurso, não o primeiro.

Maestro: um YAML, iOS e Android, zero instrumentação

Se o jeito certo é ler a árvore, eu preciso de uma ferramenta que exponha a árvore do simulador pro Claude. Tem várias. Eu fechei no Maestro, e pra quem mantém React Native e app nativo, ele ganha por três motivos concretos:

• Opera na camada de acessibilidade, sobre o binário compilado. Não importa se o app é React Native, Swift/Kotlin nativo ou Flutter. O Maestro testa o APK/IPA pronto, sem driver instalado nem mudança no código-fonte. Pra um time que toca RN e nativo lado a lado, isso é o fim de manter duas stacks de teste.
• O mesmo arquivo roda nos dois sistemas. Você escreve o flow uma vez. Roda no simulador do iPhone e no emulador do Android sem reescrever uma linha.
• YAML que humano e máquina leem. Não é código com seletor frágil. É uma sequência declarativa que o Claude gera e edita na hora.

Um flow do Maestro começa simples assim:

appId: com.suaempresa.app
---
- launchApp
- tapOn: { id: "login_button" }
- inputText: "user@nextside.tech"
- tapOn: "Entrar"
- assertVisible: "Bem-vindo"

appId, três hífens, e os comandos em linguagem quase natural: launchApp, tapOn, inputText, assertVisible. Quem nunca viu entende em dez segundos.

Onde isso fica sério é no reuso. O login se repete em todo teste, então você extrai ele uma vez e chama com runFlow:

# flows/login.yaml
appId: com.suaempresa.app
---
- launchApp: { clearState: true }
- tapOn: { id: "login_button" }
- inputText: "user@nextside.tech"
- tapOn: "Entrar"

# flows/comprar.yaml
appId: com.suaempresa.app
---
- runFlow: login.yaml          # reusa o login inteiro
- tapOn: { id: "produto_42" }
- scrollUntilVisible:
    element: { text: "Finalizar compra" }
- tapOn: "Finalizar compra"
- assertVisible: "Pedido confirmado"

Muda a regra de login num lugar, vale nos vinte testes que chamam ele. Repara no scrollUntilVisible e no clearState: true: o Maestro tem comando pra rolar até achar, limpar estado, trocar permissão, setar localização. E espera o elemento aparecer sozinho, sem você espalhar sleep pelo teste. Sleep é cheiro de teste mal feito, aqui não precisa.

Mesmo arquivo. iOS e Android. Sem tocar no código do app.

Do zero ao primeiro teste

O “como usar” de verdade começa antes do Claude. Você precisa de três coisas na máquina:

• Java 17 ou mais novo. O motor do Maestro roda em JVM. Confere com java -version.
• Xcode e o Command Line Tools. É o que destrava o simulador iOS.
• Android platform-tools com o $ANDROID_HOME setado e um emulador rodando. Confere com adb devices.

Com isso no lugar, instala o Maestro num comando:

curl -fsSL "https://get.maestro.mobile.dev" | bash
# ou, no macOS, via Homebrew:
# brew install mobile-dev-inc/tap/maestro
maestro --help   # confirma que tá vivo

Boota um simulador (ou emulador), instala seu app nele, e roda o flow:

maestro test flows/comprar.yaml      # um flow
maestro test flows/                  # a pasta inteira

Só isso já te dá teste E2E rodando local, sem IA nenhuma. A IA entra pra você parar de escrever esses YAMLs na mão.

O loop na prática: o Claude escreve o teste olhando o app

Conecta o Maestro ao Claude Code num comando:

claude mcp add maestro -- maestro mcp

Isso entrega ao Claude um punhado de ferramentas: inspect_screen (pega a view hierarchy da tela como JSON compacto), run (executa um flow) e open_maestro_viewer (embute o simulador numa janela onde você vê cada comando rodar em tempo real).

O loop que isso destrava muda o jogo:

1. Claude inspeciona a tela ao vivo. Lê a árvore, não adivinha.
2. Claude escreve o flow YAML, sem você caçar element ID na mão.
3. Claude roda no simulador.
4. Claude diagnostica o que falhou olhando a hierarquia, e conserta o próprio teste.

O passo 4 é o que mais economiza saúde. Quando um tapOn: "Entrar" quebra porque o botão virou “Acessar” numa refatoração, o fluxo manual é: teste falha no CI, alguém abre, descobre, corrige o seletor, sobe de novo. Com o loop, o Claude relê a hierarquia, vê que o rótulo mudou, troca pro id estável e te mostra o diff. Você aprova ou não. O Maestro chama isso de self-healing. É a manutenção de teste, a parte mais chata de QA, saindo das suas costas.

No React Native, o que faz esse loop ser confiável é o testID. O que você já põe nos componentes vira o id do Maestro direto:

<Button title="Entrar" testID="login_button" onPress={onLogin} />

Prefira testID a texto sempre. Texto muda com tradução e com revisão de copy. O testID só muda se você mexer nele de propósito. E quando não souber qual seletor existe numa tela, maestro studio abre um inspetor visual no browser: você clica no elemento, ele mostra os seletores disponíveis e gera o YAML do passo. É assim que você ensina o Claude a mirar nos lugares certos do seu app.

MCP ou Skill+CLI: qual usar?

Os dois funcionam. A escolha é sobre contexto. O MCP é plug-and-play: um comando e o Claude tem as ferramentas. O preço é que todo MCP carrega o schema das tools no contexto do modelo, e isso come token a cada sessão.

A alternativa é uma Skill que ensina o Claude a rodar maestro test flow.yaml direto no terminal. Mais enxuto, porque você não paga o overhead do servidor. A própria comunidade está migrando de MCP pra Skill+CLI por isso. Minha regra: começo no MCP pra explorar e prototipar rápido. Quando o fluxo vira rotina, encapsulo numa Skill com o CLI e largo o servidor.

O pedágio do iOS (a parte que ninguém posta)

Agora a parte honesta, porque vender isso como mágica é desserviço.

Primeiro: teste gerado por IA acerta 70 a 80% na primeira passada. O Claude escolhe o seletor errado, esquece um wait. O fluxo que presta é deixar a IA gerar a v1, rodar uma vez pra validar, e devolver a manutenção pra ela. Não é “manda e esquece”.

Segundo, e pesado pra quem é de mobile: o iOS cobra pedágio. Um dev documentou montar o mesmo QA nas duas plataformas. Android levou 90 minutos, o iOS passou de seis horas. A frase dele resume a década inteira de automação mobile. “Android te dá um WebSocket e diz: aqui está o app, faça o que quiser. iOS te dá uma porta trancada e um bilhete pedindo pra usar o Xcode.”

A boa notícia é que o Maestro abstrai boa parte desse pedágio, é o mesmo tapOn nos dois. Mas duas pedras você ainda vai pisar no React Native:

• Componente aninhado no iOS. O iOS “engole” o toque quando você tem um Text dentro de um TouchableOpacity dentro de outro container tocável. A correção é accessible={false} no container de fora e accessible={true} no elemento de dentro. É chato, mas é uma vez por componente.
• Expo Go não aceita launchApp. Rodando via Expo Go, o app vive dentro do container do Expo, e o launchApp com seu appId não pega. Tem que usar openLink com a URL de dev, ou fazer um development build de verdade (EAS). Em bare React Native, launchApp funciona normal.

“Vocês vão deixar um bot escrever e rodar os testes do app? Isso vai dar ruim.”

Vai dar ruim se você tratar o teste gerado como verdade e largar. Não vai se você tratar como rascunho que o sênior revisa, igual você já faz (ou devia fazer) com código que a IA escreve. O Maestro ainda te entrega o YAML versionado: dá pra ler no PR, discordar, corrigir. O teste continua sendo seu. O Claude só parou de te fazer digitar ele do zero.

De teste solto a rotina

Um teste que você roda na mão quando lembra não é rede de segurança. É teatro. O ganho real aparece quando o flow vira rotina automática. Como o Maestro é só um binário de linha de comando, ele entra em qualquer lugar que rode shell:

maestro test flows/    # roda a suíte inteira; sai com código de erro se quebrar

Esse maestro test flows/ é a mesma linha que você roda local, no GitHub Actions a cada PR, ou num cron noturno. Aquele dev do case real deixou a suíte rodando como tarefa agendada toda manhã às 8:47: boota os dois simuladores, varre as telas, analisa, e abre report do que parece quebrado. O dev acorda com o QA já feito.

O ciclo fecha aqui. O Claude escreve o flow olhando o app, o flow vira arquivo versionado, o arquivo roda no CI. A IA monta a rede, a máquina puxa ela toda noite.

A IA escreve o código e o teste. Você ainda decide o que é “funciona”.

A gente já falou aqui que a IA revisa código mas não testa software. Continua verdade, com um asterisco novo: agora ela TESTA, no simulador, navegando o app como usuário faria. O que ela não faz é decidir o que conta como “funcionou”.

Esse julgamento é seu. O critério de aceite é seu. O Maestro e o Claude tiram de você a parte chata: bootar o simulador, caçar o ID do botão, digitar o flow, rodar nos dois sistemas, consertar o seletor que mudou. Devolvem o tempo pra única coisa que a máquina não faz: olhar o app e decidir se está bom.

Ferramenta boa não substitui critério. Ela só tira a desculpa de não ter testado.

IA acelerou o dev. O gargalo migrou pra revisão. Vi time de consultoria com 2 semanas de backlog de PR esperando o tech lead revisar, e o time achando que era questão de contratar mais um sênior. Não é. O ritmo do dev mudou, o ritmo do review não. CodeRabbit consegue tirar essa fila e deixar a esteira de PR pra develop 100% autônoma em mais ou menos um mês de calibração. Funciona. Mas tem uma pegadinha: o time começa a confiar tanto na esteira que larga o reflexo de testar local. E aí o deploy quebra em staging por bug que ninguém viu rodando.

Esse post é sobre os dois lados.

IA não eliminou o gargalo. Empurrou pro tech lead.

Olha o número: código com coautoria de IA gera 1.7x mais issues por PR que código 100% humano. Fonte é o State of AI Code Generation Report do próprio CodeRabbit, analisando 470 PRs de projetos open source em dezembro de 2025. O achado é consistente com o que qualquer TL que adotou Cursor ou Claude Code no time tá vendo na prática.

Faz sentido: o dev produz mais código, mais rápido, e nem sempre com a mesma carga de contexto que tinha quando escrevia tudo na mão. Mais código + menos contexto = mais coisa pra revisar e menos confiança automática de que o autor sabe o que tá fazendo.

Olha o efeito no time:

O TL vira funil. Peguei time de consultoria onde o backlog de PR pra revisão chegou a 2 semanas. O sênior responsável tava acordando 6h pra revisar antes do daily, ficando depois do horário pra revisar antes de dormir, e ainda assim a fila crescia. O time achava que era subdimensionamento.

Não era. Code review (a etapa em que outro humano valida o PR antes do merge) virou o novo gargalo da esteira de entrega. O dev individual ficou mais rápido. O processo coletivo não.

O gargalo só anda de andar.

O mês em que o TL ensinou o bot

A jogada foi implantar o CodeRabbit (bot de AI code review que comenta linha por linha em cada PR) com o TL pilotando ele por um mês inteiro. Não foi “instala e libera geral”. Foi:

1. CodeRabbit comenta o PR
2. TL revisa em cima: confirma o que tá certo, contesta o que tá errado
3. Quando contesta, vai no .coderabbit.yaml e adiciona regra pra próxima vez
4. Quando o CodeRabbit passa batido em algo importante, vai no .coderabbit.yaml e adiciona path instruction: instrução de revisão escrita em português natural com glob de arquivo
5. Repete

Em duas semanas a quantidade de regra que o TL adicionava por dia caiu. Em três semanas o CodeRabbit acertava mais que errava. No fim do primeiro mês a curva achatou: regra nova virou exceção.

A virada de chave foi conectar duas coisas que o CodeRabbit não pega sozinho:

• Notion via MCP: todo ADR e decisão arquitetural do time fica no Notion. Conectando o CodeRabbit no Notion via MCP, ele lê o contexto antes de revisar. Acaba o tipo de comentário “isso devia usar pattern X” quando o ADR diz pra usar Y.
• JIRA na description do PR: toda PR é obrigada a citar o ID da issue JIRA. CodeRabbit puxa a US e cruza com o diff.

A segunda muda mais o jogo do que parece.

Por que exigir JIRA ID na description do PR muda o jogo?

Porque o CodeRabbit deixa de revisar só código e passa a revisar se o PR entrega a história. Os critérios de aceite estão na US? Então o bot bate cada AC contra o diff e flagra: “AC #3 fala em validação de e-mail duplicado, mas não vejo essa checagem no PR”. Aqui não é opinião: é checklist.

Só que tem um pré-requisito que pouco time quer encarar: a US precisa estar bem dimensionada e com AC escrito decente. Vejo time atrás de time falhando exatamente aí. PO cospe US gigante, vaga, com AC tipo “validar formulário”. O CodeRabbit lê isso e não consegue fazer nada com isso. Aí o pessoal acha que a ferramenta não serve. Serve. Quem não serve é o refinamento.

Sem AC bem escrito, CodeRabbit vira régua sem números.

Hoje, PR pra staging não passa mais por humano

Depois desse mês de calibração, o que mudou no fluxo:

• PR pra develop (staging): após N iterações entre dev e CodeRabbit, o próprio bot aprova. Zero humano. Merge.
• PR pra master (produção): ainda passa por humano. Sempre.

“Vocês deixam IA aprovar código sozinha. Isso vai dar ruim.”

Esse é o comentário que aparece toda vez que conto isso. Geralmente vem de alguém que nunca viu o que é um TL revisando 8 horas de PR por dia em vez de fazer arquitetura. Sim, deixa. Em staging. Onde o pior cenário é o deploy quebrar e a gente reverter. Não em produção. Em staging.

E a diferença prática: o TL voltou a fazer arquitetura. O time entrega mais. O dev pega o feedback do CodeRabbit em minutos em vez de em dias.

CodeRabbit vs GitHub Copilot Code Review vs Greptile: qual escolher?

Resposta curta: depende do que dói mais.

• CodeRabbit: line-by-line, learnings persistentes, integrações fortes (MCP, JIRA, Notion). Trade-off: ~3min por review e $24/dev/mês. Ganha em profundidade e em encaixar no workflow.
• GitHub Copilot Code Review: $10/user/mês, zero atrito porque o time já paga Copilot. Review mais raso, sem learnings persistentes, sem integração nativa com Jira/Notion. Bom pra começar.
• Greptile: bench dele mesmo diz 82% de catch contra 44% do CodeRabbit, mas gera 11 falso-positivos contra 2 do CodeRabbit. Escolha sua dor: ou perde bug ou afoga o dev em ruído.

Time pequeno que já paga Copilot: começa com Copilot Code Review e vê até onde vai. TL afogado em backlog de review: CodeRabbit paga ele mesmo no primeiro mês.

E honestidade: auditoria independente de 28 PRs revisados pelo CodeRabbit achou 15% de comentários “useless/noise” e 21% de nitpicking. Não é bala de prata. Tem que tunar. Tem que ensinar. Tem que usar os learnings. Quem instala e deixa rodando vai reclamar que é ruim. Porque é, pra esse uso.

Um arquivo, três cérebros: CLAUDE.md vira fonte única

Esse aqui é o pulo do gato que pouca gente sacou ainda.

CodeRabbit auto-detecta CLAUDE.md, AGENTS.md, .cursor/rules/*.mdc e .github/copilot-instructions.md como knowledge base. A regra que você escreve uma vez em CLAUDE.md vale pra:

1. Claude Code ao codar: segue a regra na hora de escrever
2. CodeRabbit ao revisar: bate o diff contra a mesma regra
3. Cursor ao auto-completar: respeita a convenção

Um arquivo, três cérebros lendo. Você para de manter regra duplicada em três sistemas. PR que sobe já tá quase aprovado porque foi escrito sob as mesmas regras que vão ser checadas no review.

E tem outro detalhe que fecha o loop: a CLI do CodeRabbit (coderabbit --prompt-only) cospe o feedback do review em formato consumível por agente. Dá pra montar um slash command no Claude Code que resolve os comentários em ciclo e fica empurrando back-push até o bot aprovar.

Salva isso como .claude/commands/coderabbit-loop.md no repo e usa /coderabbit-loop no Claude Code:

Resolva os comentários do CodeRabbit no PR atual até obter approve.

ANTES de aceitar qualquer sugestão, invoque o skill `receiving-code-review`
do plugin superpowers. Sem isso, vira capacho do bot.

Fluxo:
1. Execute `coderabbit --prompt-only` e capture os comentários
2. Para cada comentário:
   - Se faz sentido técnico: aplique a mudança e commite com mensagem
     ligando ao comentário ("addresses CodeRabbit: <resumo>")
   - Se NÃO faz sentido: responda no PR com justificativa técnica e
     marque como wontfix via `@coderabbitai resolve`
3. `git push` na branch
4. Aguarde re-review (polling do PR via `gh pr view` a cada 60s, máx 5min)
5. Se ainda houver comentários novos não-resolvidos, volte ao passo 2
6. Pare quando CodeRabbit aprovar OU ao atingir 5 iterações
   (nesse ponto, chame o humano: provavelmente há discordância real)

Use `gh pr view --comments` pra status. Use `gh pr comment` pra responder.
Nunca `--force-push`: commit incremental sempre.

A linha do receiving-code-review não é detalhe. É o ponto.

Sem ela, o Claude Code aceita qualquer sugestão do CodeRabbit em modo “performative agreement”: concorda pra parecer educado, refatora código que tava bom, e o PR cresce com mudança que não devia existir. O skill receiving-code-review do plugin superpowers força rigor técnico: validar a sugestão antes de aplicar, contestar quando discorda, exigir evidência. É o filtro que mantém o dev no comando, mesmo quando o dev é uma IA.

Onde a esteira quebra: o dev parou de testar local

Aqui é a parte que ninguém posta no LinkedIn.

Time com a stack completa (Claude Code + Superpowers + CodeRabbit) começa a confiar demais na esteira. O dev acha que se passou pelo CodeRabbit, tá bom. O TL acha que se o CodeRabbit aprovou, foi revisado. O QA acha que se chegou em staging, foi testado.

Resultado: NINGUÉM roda nada localmente antes do push. Vi isso acontecer em três times diferentes. Sintoma sempre o mesmo: PR mergeado em develop, deploy em staging, e aí descobre que a feature não funciona porque ninguém abriu o browser pra confirmar que o botão clica.

A IA revisa código. A IA não testa software.

A correção que adotei como inegociável: workflow obrigatório com command de validação E2E antes do push. No meu caso é um /validar-e2e que sobe a stack Docker do projeto, dispara 3 agents em paralelo (QA matrix, backend via curl/SQL, frontend via MCP Playwright no Claude Code) e só libera push quando todo cenário passa. Re-executa tudo após qualquer fix, nunca valida parcial.

Esse é o esqueleto pra adaptar ao teu projeto. Salva como .claude/commands/validar-e2e.md:

Validação E2E orquestrada antes de pedir review humano.

Sobe a stack local, gera a matriz de cenários, e SÓ DEPOIS dispara
backend + frontend em paralelo com a matriz como input. NÃO pare em
parcial. Após qualquer fix, RE-EXECUTE TUDO, não só o que mudou.

REGRA DE QUALIDADE: se um agent entregar resultado raso, sem evidência
concreta (sem log/SQL/print), com cenários pulados sem justificativa,
ou claramente incompleto: RELANCE o agent com briefing mais explícito
sobre o que faltou. Aceitar saída ruim contamina a decisão de merge.

## Fase 1: Subir/validar stack

- `docker compose -f docker-compose.e2e.yml up -d`
- Aguardar health checks responderem 200 (timeout 5min)
- Se algum serviço falhou, reporte log do container e pare

## Fase 2: Agent A: QA matrix (BLOQUEANTE, roda sozinho)

Lance UM agent e ESPERE o output completo antes de prosseguir.
Os agents B e C dependem dessa matriz: sem ela, vão testar no escuro.

Briefing do Agent A:
  Produza matriz com ≥20 cenários baseada nos commits desta branch
  vs develop. Categorias: happy path, regressão, edge cases (null/
  vazio/limites), erro (DB indisponível, auth falha), migration
  (idempotência). Para cada: ID, descrição, severidade (P0/P1/P2),
  steps, resultado esperado. Salve em
  `docs/specs/<feature>-qa-matrix.md`. Reporte contagem por
  categoria + os 3 cenários P0 prioritários + os fluxos de UI
  críticos a serem cobertos pelo frontend.

## Fase 3: Agents B e C em paralelo (alimentados pela matriz)

REGRA: UMA mensagem com 2 Agent tool calls simultâneos. Cole os 3
cenários P0 (saída do Agent A) no briefing de B e os fluxos de UI
críticos no briefing de C. Limite ≤80 tool calls por agent (acima
disso dá socket error: relance com escopo menor se crashar).

### Agent B: Backend E2E
Execute os cenários P0 abaixo via curl contra a stack local. Valide
DB após cada chamada (psql/mongosh/redis-cli conforme stack). Rode
também unit tests das branches alteradas. Reporte PASS/FAIL com
evidência (1-2 linhas de log/SQL) em ≤600 palavras. Não rebuild
Docker, não toque em código de produção.

  Cenários P0 do QA: <colar saída do Agent A aqui>

### Agent C: Frontend MCP Playwright
Execute os fluxos de UI críticos abaixo no browser via MCP Playwright.
Para cada: screenshot do estado, inspeção do console (JS errors),
validação de network requests. Reporte regressões em ≤700 palavras
com prints.

  Fluxos críticos do QA: <colar saída do Agent A aqui>

## Fase 4: Consolidar

- B e C ambos PASS com evidência → libere `git push` e abertura do PR
- Algum FAIL → corrija o código e VOLTE à Fase 3 (re-execute B e C
  com a mesma matriz; só re-rode o Agent A se o fix mudou cenários)
- BLOCKED → diagnostique infra/contexto antes de tentar de novo
- Socket error num agent → relance com escopo reduzido (≤50 tool calls)
- Resultado raso/sem evidência → RELANCE o agent com briefing reforçado
  pedindo exatamente o que faltou (logs, SQL queries, screenshots,
  asserções específicas). Não aceite PASS sem prova.

E não é só fricção burocrática: é a forma de manter o reflexo. Quem testa local pega bug em 30 segundos. Quem espera staging pega em 30 minutos. Quem espera produção paga muito mais.

A esteira é tua. A IA é só o motor.

CodeRabbit + Claude Code + Superpowers é stack. Stack boa. Tira gargalo real. Devolve tempo de TL pra arquitetura, zera backlog de review, e PR sai mais redondo porque a regra é única.

Mas é stack. Não é processo.

Processo é a disciplina de US bem escopada, AC bem escrito, teste local obrigatório, e a humildade de aceitar que a IA acelera o que tá certo e acelera junto o que tá errado.

Quem confunde stack com processo vai descobrir do jeito ruim. Provavelmente num deploy de sexta-feira.

TL;DR: MCP Playwright não é um framework de teste novo. Não substitui CI/CD. Não substitui o suite de E2E que seu engenheiro escreveu. É o seu jeito de pedir pra Claude testar local pra você, e te entregar screenshots de prova.

O fluxo de dev sempre foi: codar, escrever unit, rodar a aplicação local e testar à mão, abrir PR. O passo “rodar e testar à mão” era o que mais era pulado. “Ah, unit passou, manda pra CI.” Aí cai em produção bug que CI não pegou porque CI não cobre todo path. Com MCP Playwright, esse passo deixa de ser seu. Vira a IA navegando seu app, validando o fluxo, tirando print de cada estado relevante. Você ganha tempo. O PR ganha evidência. O CI continua fazendo o trabalho dele.

O que é MCP, sem o palavreado

MCP: Model Context Protocol é um protocolo aberto criado pela Anthropic pra ligar LLMs a ferramentas externas. Pensa em USB pra IA: padrão único, plug, e qualquer LLM compatível conversa com qualquer “MCP server” do mercado.

Antes de MCP, integrar IA com ferramenta externa era artesanal. Cada cliente (Claude Code, Cursor, Continue) tinha sua própria forma de invocar tools. Cada tool precisava de adaptador específico. Caos.

MCP padroniza isso. Você tem três pedaços:

• Cliente: o app onde a IA roda (Claude Code, Claude Desktop, etc.)
• Servidor MCP: processo separado que expõe ferramentas via protocolo. Pode rodar local, remoto, em containers, qualquer lugar.
• Tools/Resources: o que o servidor expõe. “navegue pra URL X”, “leia este arquivo”, “execute essa query”.

Cliente pergunta ao servidor o que ele oferece. Servidor responde com lista de tools. IA escolhe a tool, manda parâmetros, servidor executa, responde. Simples. Padronizado. Universal.

Tem servidor MCP pra praticamente tudo hoje: GitHub, Linear, Notion, Postgres, browser via Playwright, filesystem, Slack. Você pluga o que precisa. A IA passa a operar essas ferramentas como se fossem extensões do próprio cliente.

Playwright como MCP server: por que importa

Playwright é a stack de automação de browser do Microsoft. Headless ou não. Cross-browser (Chromium, Firefox, WebKit). API consistente, performante, com excelente DX. O que Selenium queria ser e nunca conseguiu.

Quando alguém empacota Playwright como MCP server, acontece o seguinte: o Claude ganha olhos no browser. Literalmente. Ele consegue:

• Abrir página em URL
• Tirar screenshot
• Ler o DOM via accessibility snapshot
• Clicar em elemento
• Preencher formulário
• Esperar elemento aparecer
• Verificar console por errors
• Inspecionar requisição de rede
• Executar JavaScript arbitrário no contexto da página

Tudo isso através de comandos que o LLM escolhe baseado no contexto. Você não precisa escrever spec de teste. Você descreve em linguagem natural (“valide se o card de post abre corretamente em mobile 375px”) e Claude monta a sequência: navegar, redimensionar viewport, clicar, esperar, screenshot, verificar.

Pra quem nunca usou: parece feitiço. Pra quem usou: vira hábito em 3 dias.

“Mas isso não é só mais um wrapper de Playwright?” Não. Wrapper exige você escrever código. MCP Playwright deixa a IA escolher o passo certo baseado no contexto da tarefa. Diferença não é técnica: é de abstração. Você sai do “como” e fica no “o quê”.

Fluxo real: validar UX de um post antes do commit

Pra ilustrar, fluxo que a gente da Nextside usa nesse próprio blog. Toda vez que um post novo sai do agent revisor codificado via Claude Code superpowers pronto pro commit, lança um agent dedicado de UX review que usa MCP Playwright. Sequência:

• Sobe Hugo local: hugo server -D --port 1313
• Lança o agent: descreve a tarefa: “valide o post X em light/dark e em mobile 375px/desktop 1280px”
• Claude navega via MCP Playwright: abre localhost:1313/posts/.../{slug}/, espera carregar, tira screenshot
• Inspeciona console: verifica se tem JS error, warning de fonts, ou aviso de imagem broken
• Toggle dark mode: clica no toggle de tema, espera transição, tira screenshot
• Resize pra mobile: redimensiona viewport pra 375px, screenshot
• Reporta: markdown com prints embedded + checklist (✓ contraste, ✓ tipografia, ⚠ código longo overflow em mobile, ✓ ember glow só no CTA)

Tempo total: 30 a 90 segundos. Custo: zero infra extra. Saída: relatório que eu, humano, leio em 2 minutos e decido se commito ou ajusto.

Compara com o fluxo antigo:

• Abrir manualmente no Chrome: 15s
• Abrir DevTools, simular mobile: 20s
• Ver dark mode: 10s
• Ver console: 10s
• Esquecer de testar uma das combinações pelo menos uma vez por semana: garantido

E aqui mora o ganho real. Não é velocidade: é consistência. O Claude não esquece de testar dark mode. Não pula mobile na pressa. Não diz “ah, depois eu vejo o console”. Toda vez que roda, roda tudo.

Disciplina automatizada bate disciplina humana cansada.

Antes vs depois: o que muda no fluxo do dev

Olha o fluxo tradicional. O que a gente sempre fez:

1. Coda a feature
2. Escreve teste unitário
3. Roda a aplicação local e testa à mão: clica, navega, valida visualmente
4. Abre o PR
5. CI roda Playwright + unit completos
6. Reviewer humano olha o código

O passo 3 é onde o tempo evapora. E é o mais pulado: “ah, unit passou, manda pra CI”. Aí cai em produção um bug que CI não pegou porque CI não cobre todo path possível.

Com MCP Playwright, o passo 3 vira:

3. Peço pra Claude testar: “valida o fluxo de checkout com cupom no localhost:3000, me dá screenshots de cada etapa”

E a Claude abre o browser via MCP, navega, preenche, clica, verifica, tira screenshot de cada estado, reporta erro de console se houver. Você recebe: “funcionou. Evidências em /tmp/checkout-*.png”. Anexa as screenshots no PR. Reviewer humano abre o PR com prova visual na mão. CI continua rodando o suite completo, esse não muda. O que muda é o seu passo manual de teste local.

Então isso não substitui meus testes E2E?

Não. E nem deveria. Seu E2E tradicional roda em CI sem precisar de IA, vive bem, valida regressão com determinismo. Esse é trabalho que engenheiro escreve uma vez e roda mil vezes. MCP Playwright é diferente: é o seu teste exploratório local, automatizado pela IA, com prova visual. É o passo que você fazia clicando, agora delegado.

Cenário concreto: PO escreve, IA valida

Olha como isso vira fluxo real. Quinta de manhã, o PO escreve no Notion um cenário em Gherkin:

Funcionalidade: Checkout com cupom de desconto
  Como cliente
  Quero aplicar um cupom no checkout
  Para pagar menos no pedido

  Cenário: Cupom válido aplica desconto
    Dado que estou na página de checkout
    E meu carrinho tem 2 itens somando R$ 200
    Quando eu insiro o cupom "NEXTSIDE10" no campo de desconto
    E clico em "Aplicar"
    Então o total deve cair para R$ 180
    E uma mensagem "Cupom aplicado: 10% off" deve aparecer
    E o botão "Finalizar pedido" deve continuar habilitado

A dev abre o terminal, e em vez de rodar o app e clicar ela mesma em cada passo pra confirmar que o cenário passa (aquele clique manual de pré-PR que todo mundo pula), passa pra IA:

Valida o cenário Gherkin abaixo no app rodando em http://localhost:3000.
Use o MCP Playwright. Reporta cada Then com ✅ ou ❌ + screenshot 
quando algo falhar. Não corrija o código: só audita.

<cola o Gherkin aqui>

A IA com MCP Playwright:

1. Abre o browser em http://localhost:3000/checkout
2. Valida que está na página de checkout (networkidle + <h1>Checkout</h1> visível)
3. Lê o DOM e confirma 2 itens no carrinho somando R$ 200
4. Preenche o campo “cupom” com NEXTSIDE10
5. Clica no botão “Aplicar”
6. Aguarda mudança no DOM (expect(total).toContain('180'))
7. Verifica visibilidade da mensagem “Cupom aplicado: 10% off”
8. Verifica que o botão “Finalizar pedido” continua enabled

Reporte de volta:

✅ Cenário: Cupom válido aplica desconto
  ✅ Dado: na página de checkout (h1 visível, URL correta)
  ✅ E: 2 itens, total R$ 200 (lido do .cart-total)
  ✅ Quando: cupom NEXTSIDE10 aplicado
  ✅ Então: total atualizou pra R$ 180
  ✅ E: mensagem de sucesso visível
  ❌ E: botão "Finalizar pedido" está DISABLED

Screenshot do estado final: /tmp/checkout-disabled-btn.png
Suspeita: regressão no cupom-success-handler que setou disabled=true 
por engano após aplicar desconto.

Tempo total: 35 segundos. Sem teste E2E escrito, sem stub, sem mock. Validou contra o app de verdade, no seu localhost, antes do PR ir pra review.

Mas isso não substitui CI/CD com Playwright real?

Não substitui. CI/CD continua rodando o suite completo no PR. Esse fluxo é o pre-flight: antes de você abrir o PR, antes do CI gastar 6min, antes do reviewer humano abrir tab pra ver, você já sabe que o cenário do PO passa ou falha. A regressão acima (botão DISABLED por engano) é exatamente o tipo de bug que aparece em produção 2 sprints depois porque ninguém testou esse path manual.

O Gherkin do PO virou input executável. A documentação de aceitação virou teste de aceitação rodando. Sem ninguém escrever código de teste.

O que muda vs teste E2E tradicional

Aqui um ponto importante pra não confundir. MCP Playwright não substitui sua suíte E2E em CI. ABSOLUTAMENTE NÃO. Os dois resolvem coisas diferentes, e a confusão costuma nascer porque o nome “Playwright” aparece nos dois.

O E2E tradicional é o que o engenheiro escreve em código, versiona no repositório, e que o CI roda em todo PR automaticamente. Esse não muda. Esse continua lá.

MCP Playwright é o passo 3 do fluxo do dev: aquele clique manual que você fazia (ou pulava) antes de abrir o PR. Só que agora a IA faz no lugar de você.

E2E tradicional (Playwright spec rodando em CI):

• Roda automático em todo PR: bloqueia merge se quebrar
• Especificado em código: assertion explícita, versionada, revisada
• Cobre regression suite inteira: não depende de você lembrar
• Lento: minutos por execução, exige infra de CI

MCP Playwright no Claude local:

• Roda quando você pede: não bloqueia nada por padrão
• Especificado em linguagem natural: flexível mas não versionado
• Cobre o que você descreve na hora: depende da instrução
• Rápido: segundos por execução, zero infra

Caso de uso ideal: MCP Playwright é pra a primeira camada de validação, ANTES de você pedir review humano. É o sanity check que você faria com as mãos, automatizado. Não é a rede de segurança da CI. É o pré-voo.

Suíte E2E real continua sendo necessária pra:

• Regression bloqueante em PR
• Cobertura crítica de fluxos de pagamento, auth, etc.
• Documentação executável do comportamento esperado

MCP Playwright é necessário pra:

• Sanity check rápido durante desenvolvimento
• Validação visual de feature em mudança ativa
• “Será que quebrou algo?” antes de pedir review

São complementares, não rivais. Quem trocar suíte E2E por MCP Playwright vai sentir saudade quando der refactor grande e nada quebrar no CI mas tudo quebrar em produção.

Limites e armadilhas

Calma lá. Tem armadilha:

• Não é determinístico como teste em código: você descreve “valide o card”, Claude interpreta. Duas execuções podem checar coisas levemente diferentes. Pra sanity check é OK. Pra regression bloqueante, não.
• Custo de tokens: cada screenshot consumido pelo Claude vira input. Em sessão longa, isso pesa. Cure o que você manda inspecionar.
• Falhas silenciosas: se Claude não enxergou algo, ele não reporta. Falso negativo. Você precisa instruir bem o que olhar.
• Setup do servidor MCP: instalar o MCP server local, configurar no Claude Code, garantir que browser tá disponível. Primeira vez leva tempo. Depois esquece.
• Local-only: MCP Playwright no Claude Code roda na sua máquina. Não é solução pra QA em ambiente compartilhado. Pra isso, ainda é Playwright tradicional em CI.

E tem uma armadilha de cultura: dev vira preguiçoso em escrever teste real porque “Claude testa pra mim”. Isso é cilada. MCP Playwright complementa teste, não substitui. Quem usar como substituto vai aprender da pior maneira: quando a feature crítica quebrar em produção sem teste cobrindo.

“Mas se MCP Playwright é tão bom, pra quê CI?” Porque CI bloqueia o que humano esquece. MCP Playwright só roda se você pedir. CI roda sempre. O CI é o seguro, o MCP é o pré-voo. Tira o seguro, e na primeira batida você lembra.

O que isso diz sobre o futuro do QA local

Aqui o ponto que importa.

Por muito tempo, validação local de frontend foi ruim. Você abria browser, abria DevTools, lembrava (ou não) de testar mobile, lembrava (ou não) de testar dark mode, lembrava (ou não) de checar console. Toda vez. Manualmente. Cansando.

Resultado: bug visual virava bug de produção. Não porque o dev é ruim, mas porque o cérebro humano não é máquina de checklist confiável depois de 4 horas de pair programming.

MCP Playwright muda esse jogo porque deixa o checklist virar código que outra entidade, a IA, executa por você. Você nunca mais esquece de testar dark mode. Você nunca mais comita sem ver o console. Não porque você ficou melhor, mas porque o processo agora roda sozinho. É a mesma lógica que aplicamos pra documentar decisão técnica em ADRs no Notion: tira da memória humana, bota num formato que sobrevive ao cansaço.

Isso é o que mais me empolga em MCP de modo geral: é a primeira vez que vejo automação de tarefas chatas com IA dando resultado REAL, não promessa. Playwright é só o exemplo mais maduro. Vai ter MCP server pra tudo que você odeia fazer mas precisa fazer. E quando dá pra avaliar tech nova em 2 semanas em vez de comprar a ideia inteira, Discovery é o formato certo: não precisa apostar 6 meses pra saber se MCP cabe no seu pipeline.

E o time que adotar primeiro vai ganhar consistência que time que não adotar nunca vai conseguir replicar com força de vontade.

Por isso a gente da Nextside roda MCP Playwright em todo agent de UX review. Não como gimmick de IA. Como forma de garantir que o checklist boring acontece toda vez, sem depender de eu lembrar às 23h de sexta.

A IA cansa menos que você. Use isso a seu favor.

A letra miúda é: depende do seu nível de senioridade pra cobrir o que a IA não cobre, e da metodologia que você consegue manter na cabeça. Pra 1-2 tarefas em paralelo, vibe coding com Claude Code resolve. Pra 5-6 tarefas simultâneas, onde a Nextside vive, a cabeça humana não aguenta. Aí entra metodologia codificada.

Superpowers é a metodologia codificada num plugin: skills, agents, slash commands, hooks. Em vez de você reinventar SDD (Spec-Driven Development) e harness engineering próprios, o que custa semanas de R&D, você usa o que milhares de devs estão validando em paralelo. Bug fix do plugin chega pra você de graça. Feature nova chega pra você de graça. É open-source funcionando do jeito que open-source deveria.

Eu testei. A gente testou. Esse blog que você está lendo foi construído com Claude Code + superpowers do começo ao fim: design system, layouts Hugo, pipeline de agents, frontmatter, esse próprio post. E o que mais me chamou atenção não foi velocidade. Foi disciplina.

Claude Code puro com Vibe Coding funciona, até quebrar

O Fabio Akita escreveu sobre Agile Vibe Coding e tem razão. Você pode entregar feature inteira em 30min usando Claude Code puro, conversando com a IA, iterando rápido. Vibe.

E funciona. Pra 1 tarefa. Pra 2 tarefas.

Então pra que o plugin?

Porque o trabalho real da Nextside não é 1 tarefa. É 5. Às vezes 6.

Vibe coding com 1 contexto = produtivo. Vibe coding mudando de contexto a cada 15min = sua cabeça em pedaços às 17h, sem entregar nada sólido.

Quando o paralelismo entra, vibe não basta. Você precisa de:

• Brainstorming forçado antes de codificar: pra não começar a tarefa errada
• Testes obrigatórios na hora do código: pra não voltar pra debugar em 2 dias
• Plano escrito por agent: pra você ler depois e lembrar onde estava
• UX-review automático: pra não esquecer de checar o resultado visual
• Skill com checklist: pra cada tipo de tarefa rodar do mesmo jeito

Você pode construir tudo isso sozinho. Vai gastar 2-3 semanas, validar com seu time, debugar a primeira iteração. Ou usar o plugin superpowers que já tem isso, e ganhar features novas que outros engenheiros já validaram.

Plugin não te tira a vibe. Tira a bagunça da paralelização. Continua sendo você no comando, só com guarda-corpo onde a fadiga humana já trairia o resultado.

O que é superpowers, sem hype

Superpowers é um plugin pro Claude Code (claude.ai/code, a CLI da Anthropic) que adiciona três coisas concretas:

• Skills: markdown files que descrevem “como fazer X”. Cada skill tem trigger (quando usar), passos (o que fazer), e regras (o que não esquecer). Claude lê a skill antes de executar a tarefa.
• Agents/Subagents: invocações especializadas. Você lança um “subagent de revisão UX” que tem contexto próprio, prompts próprios, e ferramentas próprias. Não polui contexto principal.
• Slash commands: atalhos que você digita (/code-review, /ship, /init) e disparam fluxos complexos. Cada um lê o repo, executa passos, e reporta.

Soa parecido com prompts salvos? É. Mas a diferença não é o conteúdo: é o ritual. Skill enforced significa que o Claude lê a skill ANTES de começar a trabalhar. Não tem chance de pular o passo de TDD. Não tem chance de pular o checkpoint de brainstorming. A skill é gatilho automático.

E é aí que mora a virada.

Como muda o fluxo de trabalho real

Sem superpowers, Claude Code é IA generalista boa. Você abre, descreve a tarefa, ele tenta resolver. Se você esquecer de pedir teste, ele não escreve teste. Se você esquecer de pedir brainstorming antes de codar, ele já parte pra implementação. Resultado: muito código gerado, muito código jogado fora.

Com superpowers, o jogo é outro:

• TDD enforced: skill test-driven-development força Claude a escrever teste falhando ANTES de escrever implementação. Sempre. Pra todo bugfix, pra toda feature. Não negocia.
• Brainstorming antes de código: skill brainstorming exige que, antes de qualquer trabalho criativo, Claude explore o problema com o usuário. Faz perguntas. Lista alternativas. Só depois propõe solução.
• Systematic debugging: encontrou bug? Skill systematic-debugging força investigação metódica em vez de chute. Primeira hipótese não é a aposta. É o ponto de partida da árvore de causas.
• Verification before completion: Claude não pode dizer “feito” sem rodar verificação. Roda os testes, mostra output, depois afirma. Adeus “deve funcionar”.

Notem o padrão: cada skill é uma forma de codificar disciplina de engenharia sênior. O que devs experientes fazem por hábito (TDD, brainstorming antes de código, debug metódico, verificar antes de afirmar) vira regra que a máquina executa.

E aqui mora o ponto: isso não é sobre dar superpoder pra IA. É sobre dar a IA o conjunto de hábitos do seu melhor dev sênior.

Como a Nextside usou pra construir o próprio blog

A gente da Nextside montou esse blog (blog.nextside.tech) usando Claude Code + superpowers. Stack: Hugo + tema Hextra, design system próprio em CSS, pipeline editorial de agents, bilíngue pt-BR/EN.

Fluxo típico de uma feature do design system:

1. Brainstorming session: eu descrevo “preciso de hover state pro card de post”. Claude (via skill brainstorming) faz 3-4 perguntas: “ember glow ou só elevation?”, “mobile também ou só desktop?”, “comportamento em dark mode?”. Só depois disso propõe abordagem.
2. Plano escrito: skill writing-plans força Claude a escrever plano detalhado antes de codar. Plano vai pra um arquivo de spec. Eu reviso. Aprovo ou peço ajuste.
3. Execução com TDD: skill executing-plans segue o plano. Cada passo do plano vira checkpoint. Skill TDD força teste antes de código (quando aplicável: em CSS puro, vira verificação visual).
4. UX review automática: antes do commit, lança um agent dedicado de revisão UX que abre o site no browser via MCP Playwright, navega, tira screenshot, e flagra problema.
5. Commit + push: só depois de tudo verde.

Notem: zero “vibe coding” desorganizado. Zero “deixa eu tentar uma coisa”. Zero “deve funcionar”. É um pipeline.

E o resultado vem porque o pipeline é repetível. A próxima feature passa pelos mesmos checkpoints. A skill é a mesma. O agent é o mesmo. Não depende da minha memória de “o que eu pedi da última vez”.

Isso é o que muda em time. Quando o conhecimento tá codificado em skill, qualquer dev do time invoca o mesmo Claude e ganha o mesmo padrão. Não tem dev “que sabe usar Claude bem” e dev “que não sabe”. O conhecimento mora no plugin.

O que melhora vs Claude Code puro

Diferença concreta de antes e depois:

• Velocidade real (não percebida): Claude puro entrega rápido demais. Você acha que economizou tempo, mas gastou 2h refazendo. Com superpowers, primeira entrega leva um pouco mais, porque tem brainstorming, plano, TDD, mas é a entrega que fica.
• Menos slop: slop é código gerado que parece certo mas tá errado. Sem superpowers, slop aparece direto. Com superpowers, o verification step pega antes do commit.
• Reprodutibilidade: outro dev do time invoca o mesmo /code-review e ganha review com critérios idênticos aos meus. Não depende do prompt que eu escrevi às 3 da manhã num sábado.
• Onboarding mais rápido: dev novo no time não precisa decorar processo. Ele instala superpowers, lê o catálogo de skills e slash commands, e já trabalha como o time trabalha.

A última é a que mais me surpreendeu. Eu sempre achei que “processo de time” era doc no Notion. Vira que não: é skill no Claude. Doc no Notion ninguém lê. Skill no Claude executa toda vez que a tarefa começa.

Isso é importante: doc de processo é ficção. Skill executada é processo de verdade.

Limites honestos (não é mágica)

Calma lá. Superpowers não resolve tudo:

• Não substitui dev sênior: substitui o trabalho braçal do dev sênior. As decisões arquiteturais reais ainda exigem humano no loop. Quem escolhe stack, quem decide trade-off de performance vs DX, quem faz call de produto, é gente.
• Slip pode escapar: verification step não é onisciente. Se o teste tá errado, o “tudo verde” é falso positivo. Você ainda precisa olhar.
• Custo de contexto: skills enchem o contexto inicial. Se você tem 30 skills carregadas e o repo é gigante, performance cai. Tem que curar skill ativa.
• Aprende mal sozinho: superpowers não evolui sozinho. Se um padrão do time muda, alguém tem que atualizar a skill. Sem manutenção, ela vira obsoleta, e aí a IA executa processo velho com convicção.

E o ponto crítico: superpowers é alavanca, não autopilot. Você ainda precisa pensar. Você precisa revisar o plano que Claude escreveu. Você precisa decidir quando a brainstorming session já durou demais. A skill é régua, mas você é quem segura a régua.

“Mas se a IA faz tudo, qual é o papel do dev?” Boa pergunta. Resposta: o dev vira arquiteto + revisor + ditador de gosto. Não digita mais boilerplate. Decide o quê, revisa o como, e ajusta o tom. É papel mais sênior, não menos.

O que esse plugin diz sobre o futuro do trabalho

Aqui o ponto que mais importa.

Por anos, processo de time foi documento. ADR no Notion. Checklist no Confluence. Playbook no Google Doc. Tudo passivo. Tudo ignorado depois da segunda semana.

Superpowers muda isso porque transforma processo em código executável pela IA. A skill não é doc: é instrução que dispara toda vez que a tarefa começa. Ninguém precisa lembrar de “rodar o playbook”. A IA roda sozinha.

Isso tem implicação grande: o conhecimento de engenharia que ficava nas cabeças dos seniores agora cabe num markdown que outro membro do time invoca via slash command. Conhecimento codificado, executado por máquina, escalado pra todo time.

Não é mágica. Não substitui senioridade. Mas é a primeira vez que eu vejo “processo de time” sair do papel e virar comportamento real e repetível, sem depender de alguém policiar.

E isso muda jogo. Ponto.

Por isso a gente da Nextside roda Claude Code + superpowers em todo Sprint de 4 semanas. Não como ferramenta de produtividade. Como forma de garantir que o jeito Nextside de trabalhar acontece toda vez, sem precisar do humano lembrar.

Quem documenta processo em PDF tá lutando guerra antiga. Quem codifica processo em skill tá entregando enquanto o outro escreve playbook.

ADR: Architecture Decision Record é registro de decisão técnica. Curto. Datado. Imutável. Você decide algo importante hoje, escreve por que decidiu, e daqui a 6 meses quando alguém perguntar “por que diabos a gente escolheu Postgres em vez de Mongo?”, a resposta tá lá. Sem ter que reconvocar a reunião perdida no calendário de fevereiro.

O ponto não é o template. O ponto é não perder história.

Por que a maioria dos times falha em ADR

A maioria dos times que tenta adotar ADR copia o template do Michael Nygard (ou o do AWS prescriptive guidance, ou o do ThoughtWorks) na primeira semana, escreve 3 ADRs em 4 dias, e abandona no quinto. Eu já fiz isso. Time pequeno tem zero paciência pra ritual.

O problema é simples: o template tradicional tem 6 seções (Context, Decision, Status, Consequences, Alternatives Considered, Stakeholders). Em time de 4 pessoas com prazo apertado, ninguém escreve “Alternatives Considered” com bullet points. Ninguém. Você abre o doc, olha pra 6 headers vazios, fecha o doc, e volta pro código.

Resultado: o ADR vira piada. “Cara, lembra quando a gente ia documentar decisões? Bons tempos.”

“Mas se vocês não documentam direito, como mantêm histórico?” Pergunta justa. Resposta: a gente documenta SIM, só que num formato que cabe em time pequeno. Não no formato que cabe num livro de arquitetura corporativa.

E é aí que mora a diferença. ADR de time pequeno não é “Architecture Decision Record” no sentido pomposo. É bilhete pro seu eu do futuro. Você está escrevendo pra você daqui a 4 meses, que esqueceu por que escolheu Redis em vez de Memcached. Isso é tudo.

Como a gente da Nextside faz no Notion

Não tem repo separado pra ADRs. Não tem docs/adr/0001-use-postgres.md. Tem uma database no Notion chamada Decisões. Schema bobo:

• Title: frase declarativa curta: “Usar Postgres como banco principal”, “Adotar Hugo em vez de Next pro blog”
• Status: Proposta / Aceita / Substituída / Descartada
• Data: quando foi decidida
• Tags: área (backend, frontend, infra, processo)
• Body: 3 seções: Contexto (1-3 parágrafos), Decisão (1 parágrafo seco), Consequências (bullets curtos: o que ganhamos, o que perdemos)

E só.

Notem o que NÃO tem: “Stakeholders”, “Voting”, “Alternatives Considered” formalizado. Se as alternativas importam, viram parágrafo no Contexto. Se não importam, não viram nada. O critério é simples: o ADR existe pra alguém entender a decisão daqui a 6 meses, não pra defender em auditoria.

A regra de ouro que a gente segue: se você decidiu algo que vai ser caro reverter, escreve um ADR. Se vai dar pra reverter num PR de 50 linhas, não escreve nada. Documentar tudo é o mesmo que documentar nada: vira ruído.

Exemplo concreto (decisão real-ish)

Cenário típico: time precisa decidir entre dois ORMs num projeto Node novo. Prisma vs Drizzle. Discussão dura 40 minutos no Slack. Alguém abre o Notion e escreve:

Título: Usar Drizzle como ORM no projeto X

Status: Aceita

Data: 2026-04-12

Contexto: Projeto X precisa de ORM com bom suporte a TypeScript, migrations versionadas e performance previsível em query analytics. Avaliamos Prisma (mais maduro, melhor DX, mas runtime engine em Rust pesa cold-start em serverless) e Drizzle (mais novo, zero-cost abstraction, SQL-first). Time já tem familiaridade com SQL puro.

Decisão: Adotar Drizzle. SQL-first encaixa no perfil do time, cold-start em serverless é problema concreto pra esse projeto, e a curva de aprendizado é menor que o ganho de DX do Prisma.

Consequências:

• Ganhamos cold-start mais rápido em Vercel/AWS Lambda
• Perdemos algumas features avançadas que Prisma tem out-of-the-box (Prisma Studio, melhor introspection)
• Migrations ficam mais manuais: exige disciplina maior do time
• Se ferrar, dá pra migrar pra Prisma. Drizzle é fininho, sem lock-in pesado

Pronto. 180 palavras. 4 minutos pra escrever. Daqui a 6 meses, quando um dev novo chegar e perguntar “por que Drizzle?”, a resposta tá ali, datada, com contexto.

Isso é todo o segredo. Não tem mágica.

O que acontece quando você NÃO faz isso

O que acontece é o que eu chamo de history losing. Decisão tomada, ninguém anotou, 6 meses depois o time inteiro esqueceu. Aí surge a tentação de revisitar a decisão. “Cara, será que a gente devia ter usado Prisma?” Discussão de 40 minutos. De novo. As mesmas 4 pessoas. Com mais ou menos os mesmos argumentos. Conclusão idêntica.

Você acabou de pagar o preço da decisão DUAS VEZES.

Pior: às vezes a conclusão é diferente, porque alguém esqueceu o argumento crítico que pesou da primeira vez. Aí o time muda de Drizzle pra Prisma, refatora tudo, e 3 meses depois bate no mesmo problema de cold-start que motivou Drizzle originalmente. Voltamos pra Drizzle. Mais 3 meses queimados.

Isso é a pior coisa que pode acontecer em time pequeno: repetir burrice porque ninguém anotou a burrice anterior. Empresa grande aguenta. Time de 4 pessoas, não.

Memória institucional num time pequeno não é Confluence. É hábito.

ADR não substitui conversa. Não substitui pair programming. Não substitui RFC pra coisa grande, que cabe melhor num Discovery dedicado. Mas substitui o “espera, deixa eu lembrar por que a gente decidiu isso…”. E esse “espera, deixa eu lembrar” custa mais caro do que parece. Custa contexto interrompido, custa retrabalho, e custa confiança no histórico do time.

“Mas ninguém vai voltar ler ADR depois!” Vão sim. Eu volto. Toda vez que entro num projeto antigo e me pergunto “por quê?”. O ADR é o atalho pro porquê. Sem ele, atalho some.

Como começar amanhã (sem virar processo pesado)

Se você nunca teve ADR no time e quer começar, três passos:

• Cria uma database no Notion (ou Linear, ou Trello, ou um diretório docs/decisoes/ no monorepo). Não importa a ferramenta. Importa ter UM lugar.
• Define a regra de gatilho: qualquer decisão que custaria 1+ dia pra reverter merece ADR. Decisão de framework, banco, padrão de auth, escolha de fila, padrão de erro. Decisão de naming de variável NÃO precisa.
• Bota gatilho no PR template: pergunta opcional no template: “Essa PR introduz decisão arquitetural? Se sim, link do ADR”. Soft enforcement. Sem isso, o hábito morre na segunda semana.

Em 3 meses, o time tem 10-15 ADRs. Em 1 ano, 30-40. Não é volume. É densidade de contexto. Cada ADR é um sinal claro de “aqui tomamos uma decisão que importava”.

E aqui mora o detalhe que ninguém fala: o valor real do ADR não tá no documento. Tá no ato de escrever. Quando você senta pra explicar a decisão em 3 parágrafos, você descobre que metade da decisão tava implícita e mal formada. O ADR força clareza. É o pair-programming da decisão técnica.

Quem quiser ir além e codificar o processo em skill que a IA executa, pra que o ato de escrever ADR vire gatilho automático, esse é o próximo passo natural. Mas começa pelo hábito humano. Skill sem hábito por trás é teatro.

Por isso eu nem ligo se ninguém ler depois. Já valeu pelo ato de escrever.

INDEX dos ADRs: o ponto que ninguém ainda fala

Aqui vai a parte que mudou pra mim em 2026.

ADR é ótimo pro humano. Sócio entra no time, abre docs/adr/0042-prisma-vs-sequelize.md, entende a decisão em 5min. Bom.

Mas agora a IA também lê seu repo. E ela precisa de índice, não de busca por força bruta.

Mas a IA não consegue só grep no diretório?

Consegue. E enche o contexto com 47 ADRs irrelevantes pra responder uma pergunta. Custa token, custa qualidade, custa tempo.

A solução veio do próprio Claude Code: o sistema de auto-memória dele usa um arquivo MEMORY.md que é só index: cada linha aponta pra um arquivo de memória detalhado com uma descrição de 1 linha. Quando o Claude precisa decidir algo, ele lê o MEMORY.md (200 linhas máximo), escolhe a memória relevante, e só aí abre o arquivo detalhado.

O paralelo pra ADRs é exato. No nosso Notion (ou em docs/adr/INDEX.md se você usa repo), faz uma página INDEX no mesmo nível dos ADRs:

- [ADR-0042 Prisma sobre Sequelize](./0042-prisma-vs-sequelize.md): Postgres com tipagem forte; rejeita Sequelize por dor de migração
- [ADR-0043 Server Components no Next 15](./0043-rsc-next-15.md): Default; só "use client" onde tem interação real
- [ADR-0044 Sem Redux](./0044-sem-redux.md): Zustand pra estado global pequeno; URL state pro resto

Uma linha por ADR. Descrição que cabe em search.

Agora o Claude (ou qualquer outra IA) chega no seu repo, lê o INDEX.md em 2s, decide quais 2-3 ADRs são relevantes pro problema em mãos, e carrega só esses no contexto. A diferença entre 3 ADRs lidos e 47 é a diferença entre IA útil e IA confusa.

E o melhor: você ganha o índice de graça. Humano novo também usa. Sem custo adicional.

Sem INDEX, seus ADRs viram cemitério de documentação ótima que ninguém lê: nem humano, nem IA.

Configurando ADRs no seu Claude

Tem o INDEX. Humano usa. Ótimo. Mas o pulo do gato é fazer a IA usar do jeito certo, sem você lembrar de mandar.

Esse blog roda em Claude Code + superpowers. Quando a gente executa um spec do superpowers, a skill que força brainstorming, plano escrito, TDD, verification, decisões arquiteturais aparecem naturalmente no meio do caminho. “Vai ser Drizzle ou Prisma?” “Server Component default?” Cada uma é candidata a ADR.

Mas IA esquece.

Pede pra anotar uma vez, ela anota. Próxima sessão, esqueceu. Por isso a anotação precisa virar instrução de sistema, não pedido.

CLAUDE.md aponta pra ADR (e pro INDEX)

Claude Code carrega um arquivo CLAUDE.md na raiz do projeto em TODA sessão. É a memória padrão do projeto, o equivalente em IA do “leia isso antes de tudo”. Você não manda. Ela lê sozinha.

Lá embaixo, sem ritual:

## Architecture Decision Records

Consulte `docs/adr/INDEX.md` antes de tomar qualquer decisão técnica significativa.
- Se uma ADR existente cobre o assunto, siga.
- Se a decisão é nova e cara de reverter, proponha nova ADR ao final do plano.
- Toda nova ADR entra no INDEX no mesmo PR.

Pronto. 4 linhas. A IA passa a consultar o INDEX sempre que entra em modo de planejamento.

O detalhe que importa: não enche o CLAUDE.md com 47 ADRs in-line. Aponta pro INDEX. CLAUDE.md é carregado em TODA sessão: cada token gasto ali rouba contexto de coisa útil. Mantém leve. Aponta. Confia no INDEX pra fazer o resto.

E se a IA ignorar a instrução?

Vai ignorar uma ou outra vez, sim. Por isso entra o segundo pilar.

Slash command /adr pra forçar o ritual

CLAUDE.md é leitura passiva: a IA usa se lembrar. Slash command é ATIVO: você dispara, ela executa. No Claude Code, basta criar .claude/commands/adr.md no repo:

Planeje uma nova tarefa:

- Leia `docs/adr/INDEX.md` e identifique ADRs relevantes a: $ARGUMENTS
- Carregue só os ADRs relevantes no contexto (não todos)
- Se a tarefa introduz decisão arquitetural NOVA, proponha rascunho de ADR antes do plano técnico
- Se a tarefa muda ou supersede ADR existente, sinalize explicitamente
- Toda ADR nova precisa ser confirmada por mim antes de virar arquivo em `docs/adr/`

Daí o fluxo diário vira:

/adr Migrar autenticação de JWT pra session cookie

Claude lê o INDEX, identifica a ADR-0023 (que escolheu JWT originalmente), carrega só ela, e propõe ADR-0044 supersedindo. Você revisa. Aprova. Vai pra implementação.

Sem /adr, você dependeria de lembrar de mandar a IA consultar histórico. Com /adr, o ritual está no slash command. A IA não pula. Você não esquece.

Integrando com superpowers

E aqui mora a beleza. Se você já roda superpowers, a skill writing-plans força plano escrito antes de código. A skill brainstorming força exploração antes de implementação. Encaixar ADR nesse fluxo é uma linha no CLAUDE.md:

## Regras invioláveis
- Todo plano gerado pela skill `writing-plans` referencia ADRs relevantes no início.
- Toda decisão arquitetural detectada por `brainstorming` vira candidata a ADR. Propõe rascunho ao usuário.

A skill superpowers já tem o gatilho de “antes de codar, planeje”. Agora o plano sai com ADRs citados. E decisão nova já sai com rascunho de ADR pronto pro humano aprovar.

ADR deixa de ser tarefa separada que você esquece. Vira subproduto natural do fluxo de spec → plano → código. Vem de graça.

Onde colocar o quê

Claude Code carrega CLAUDE.md em três níveis: global (~/.claude/CLAUDE.md), projeto (./CLAUDE.md) e subdiretório (./modulo/CLAUDE.md). Mais específico ganha de mais geral.

Pra ADR, a regra que eu uso:

• Global: nada de ADR aqui. Suas convenções pessoais de código, sim. ADR é do time, não seu.
• Projeto: referencia docs/adr/INDEX.md. Lista as 3-5 ADRs mais críticas (banco, framework, padrão de auth) explicitamente, pra IA não precisar abrir o INDEX em 90% dos casos.
• Subdiretório: só se um módulo tem decisões que só valem ali. Raro. Não force.

Maioria dos times só precisa do nível projeto. Não complica.

Três armadilhas

• Não cole ADRs in-line no CLAUDE.md. Vira arquivo de 800 linhas, performance da IA cai, e você perdeu o ganho do INDEX.
• Não deixe a IA escrever ADR sozinha sem aprovação humana. ADR é decisão. Decisão exige humano. IA propõe rascunho, humano aprova. Sempre.
• Não esqueça de atualizar o INDEX quando criar ADR nova. O INDEX é o contrato. Se a ADR existe mas não tá no INDEX, ela não existe pra IA.

Skill sem ritual humano é teatro. Ritual humano sem skill é fadiga. Os dois juntos é como ADR fica vivo num time pequeno usando IA pesada.

O que o ADR realmente protege

O ADR não protege você de tomar decisão errada. ABSOLUTAMENTE NÃO. Você vai tomar decisão errada de qualquer jeito. Todo time toma. O ADR protege você de tomar a MESMA decisão errada duas vezes. Que é coisa diferente.

Time bom não é o time que acerta sempre. É o time que erra menos a cada iteração. ADR é o registro que permite saber qual erro você cometeu e por quê, pra não cometer outra vez na próxima decisão parecida. É o equivalente, em decisão de produto, da validação local com qualidade real que a gente faz via MCP Playwright em frontend: você não previne todo erro, mas garante que erros viram aprendizado registrado.

Em time pequeno, a margem pra repetir burrice é zero. Cada semana queimada em decisão refeita é semana que você não tinha. Discovery, MVP, refatoração: não tem folga.

Por isso a gente da Nextside escreve ADR no Notion. Curto. Datado. Honesto. Sem template gigante. Sem cerimônia. Sem reunião extra.

ADR não é para impressionar auditor. É para o time. E o time é pequeno. E o tempo é curto.

Quem não anota a história, repete a história. E repetir burrice é o luxo que time pequeno não pode pagar.

Gosto de transformar ideia em solução que gera valor rápido — ou de encerrar a ideia rápido pra não queimar investimento. Foco em plataformas SaaS, arquitetura na AWS, IA aplicada com pragmatismo e times pequenos de alta performance. Também empreendo, avalio novos negócios e invisto em startups. Gosto de medir, testar e ajustar.

Aqui no blog escrevo sobre arquitetura que aguenta produção, IA aplicada com critério e como tirar um MVP da garagem sem virar gambiarra.

A Nextside entrega Sprints de 4 semanas, Discoveries técnicas e Auditorias. Este blog é onde a gente conta — em primeira pessoa, sem corporativês — como pensamos, o que funciona, e o que dá errado.

Quem escreve

Sócios e engenheiros sêniores da Nextside. Cada post tem um nome, uma foto e um LinkedIn embaixo. Sem ghost-writer.

Sobre o que escrevemos

• Tecnologia — IA aplicada, stacks, arquitetura, decisões técnicas
• Gestão — como rodamos times pequenos com gente cara
• Entregas rápidas — o método Sprint, escopo fechado, MVPs em 4 semanas
• Cases — relatos com clientes (autorizados), bastidores, números

Com quem falar

• Quer contratar um Sprint, Discovery ou Auditoria? → nextside.tech
• Quer trabalhar com a gente? → LinkedIn da Nextside
• Quer só conversar sobre um post? → LinkedIn ou X do autor

Sem newsletter, sem pop-up, sem fórmula. Você lê, decide se gosta, volta.