# Blog Nextside (versão expandida)

> Posts da Nextside sobre engenharia de software, IA aplicada com critério, ADRs, harness engineering e consultoria pragmática para founders e CTOs.

URL: https://blog.nextside.tech
Idioma: pt-BR (default), en
Publisher: Nextside Ltda. (CNPJ 66.475.888/0001-27)
Site institucional: https://www.nextside.tech
Última atualização: 2026-06-22

## Páginas

- [Home (pt-BR)](https://blog.nextside.tech/): índice dos posts mais recentes.
- [Home (en)](https://blog.nextside.tech/en/): English index.
- [Sobre](https://blog.nextside.tech/sobre/): por que este blog existe.
- [Tags](https://blog.nextside.tech/tags/): índice de tópicos.

## Editorial

Este blog é onde sócios e engenheiros sêniores da Nextside contam, em primeira pessoa e sem corporativês, como pensam, o que funciona, e o que dá errado. Posts são opinião informada por experiência prática, não tutoriais genéricos nem conteúdo SEO commodity. Cobertura: engenharia com IA (Claude Code, MCP, harness engineering), gestão técnica (ADRs, escopo fechado, sprint zero), consultoria pragmática. Frequência alvo: 1 post novo por mês. Cada post tem cover ilustrado, autor identificado, datePublished + dateModified visíveis. Sem newsletter, sem pop-up, sem fórmula.

Eixos editoriais:

- **Tecnologia**: IA aplicada, stacks, arquitetura, decisões técnicas.
- **Gestão**: como rodar 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.

## Posts

### [Quanto cobrar por uma ferramenta: margem não é dev barato](https://blog.nextside.tech/posts/2026/06/22/quanto-cobrar-por-uma-ferramenta/)

**Data:** 2026-06-22 · **Tags:** agencias, precificacao, white-label, ferramentas-web, margem · **Autor:** Pablo Winter

**Tese central:** quando uma agência (ICP A, não-tech) revende uma ferramenta web ao cliente final, a margem não vem de caçar o dev mais barato; vem de revender uma entrega previsível que não volta com bug na frente do cliente. O reflexo de procurar o freela mais barato faz sentido na planilha e quebra na entrega, porque o preço do dev é só uma fatia da conta. O que não está na proposta (retrabalho quando a primeira versão volta torta, as semanas de atraso, a ferramenta que cai numa segunda de campanha grande) é o que de fato decide se sobrou margem, e tudo isso sai do bolso da agência, parcelado em dor. O número que ancora: 78% das agências raramente ou nunca cobram quando o escopo cresce no meio do caminho (Ignition, 2025), então o dinheiro vaza antes mesmo do fornecedor sumir.

O post ataca o erro estrutural de precificar ferramenta com a régua de site (por página, por hora de design, por tela). Site mostra, ferramenta faz, e "fazer" é onde mora o custo: a lógica de negócio invisível ao cliente, a integração com estoque/CRM/pagamento, o que sustenta depois (login, dados de usuário, segurança) e a escala quando a campanha viraliza. Uma tabela dá ordem de grandeza honesta sem fingir precisão, da calculadora de lead (a mais barata) à ferramenta com login e dados de usuário (a mais alta), deixando claro que duas coisas chamadas "ferramenta" podem ter dez vezes de diferença de custo. A saída para precificar sem saber o custo do dev é não chutar: pedir uma faixa fechada a um parceiro técnico antes de fechar com o cliente, remarcar com a própria margem, e assinar sabendo exatamente quanto sobra. É a diferença entre orçamento aberto (convite à surpresa, começa em X e vira 2X) e escopo fechado.

A virada é o modelo white-label: a agência não revende desenvolvimento, revende o resultado com a própria marca na frente, e o fornecedor fica invisível. O markup de revenda costuma ficar entre 40% e 70% sobre o custo da entrega (CloudCampaign), mas só sobrevive se a entrega não voltar; cada projeto com bug, prazo estourado ou fornecedor sumido come essa margem inteira. O post fecha com a conta de um configurador de R$ 30 mil: o Caminho A (freela de R$ 8 mil que atrasa e empurra o lançamento de abril pra junho) transforma a margem gorda em prejuízo de reputação; o Caminho B (parceiro previsível de R$ 15 mil, escopo travado, no prazo) entrega uma margem menor no papel mas que de fato entra, e ainda traz o cliente de volta com o próximo projeto. É o pilar P6 de precificação para agências, cruzando com "Cliente pediu uma ferramenta e seu time não dá conta" (o momento anterior, quando o time trava antes do preço) e com "o que cortar e o que manter num MVP" (escopo fechado), e amarra na oferta de Discovery da Nextside para o cliente dar uma faixa fechada antes de fechar o projeto.

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

### [Recebi um MVP vibe-coded pra escalar: o diagnóstico honesto](https://blog.nextside.tech/posts/2026/06/19/recebi-mvp-vibe-coded-pra-escalar/)

**Data:** 2026-06-19 · **Tags:** vibe-coding, divida-tecnica, refatoracao, mvp, arquitetura, testes · **Autor:** Pablo Winter

**Tese central:** diante de um MVP vibe-coded (software gerado pedindo pra IA e aceitando o resultado sem ler o código) que funciona o bastante pra ter cliente pagando mas trava na hora de escalar, a primeira decisão não é técnica, é de triagem. A tentação mais cara, que quase todo mundo tem no primeiro dia, é mandar reescrever tudo do zero, e quase sempre é erro. Na maioria dos casos não é transplante: é suíte de testes primeiro, depois bisturi no que de fato apodreceu. Os números assustam de propósito (45% do código gerado por IA carrega uma falha do OWASP Top 10 pela Veracode; só 10,5% passa num review de segurança decente pela Carnegie Mellon), mas medem a distância entre funcionar e aguentar, distância que se mede antes de demolir, não depois.

O post ataca o reflexo de reescrever do zero invocando Joel Spolsky, que em 2000 já chamava isso de "o pior erro estratégico que uma empresa de software pode cometer". O argumento: você jogaria fora a única coisa que o MVP provou, que tem gente querendo, e cada gambiarra esquisita costuma codificar um caso de borda real que a versão "limpa" vai redescobrir do jeito difícil, em produção. O exemplo do Twitter nascendo num monólito Rails fecha o raciocínio: 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. Antes de tocar em qualquer linha vem a suíte de testes, e não cobertura total: teste nos fluxos que dão dinheiro e nos que perdem dinheiro (checkout, login, saldo), porque o código vibe-coded tem viés brutal de caminho feliz e ignora erro de rede, input inválido, duplo clique.

O diagnóstico (ler o extrato da dívida) quase sempre encontra os mesmos quatro buracos: arquitetura acoplada (regra de negócio grudada na infra, o flow-debt trade-off), observabilidade ausente, segurança de enfeite (chave hardcoded, auth invertida; a Apiiro mediu 10x mais achados de segurança em seis meses, escalonamento de privilégio subindo 322%) e deploy/CI frágeis (o caso da IA da Replit que apagou o banco de produção durante um congelamento de código). O critério pra salvar ou reescrever um pedaço é o acoplamento entre regra de negócio e infra: regra isolada, mesmo feia, é remediação; regra enfiada no controller dependente do banco é reescrita localizada. Salva-se quase sempre o modelo de domínio, os fluxos validados e boa parte da interface; reescreve-se sem dó auth/permissão, a lógica que a IA duplicou em dez lugares (em 2024 código copiado superou refatorado pela primeira vez, blocos duplicados crescendo 8x pela GitClear), schema sem tração e integrações sem fallback. O 70% problem de Addy Osmani explica onde o app empaca: a IA leva rápido a 70% do volume de código, não do caminho até produto pronto.

Estabilizar sem parar o negócio é a peça que mais diferencia um resgate competente, porque o app está no ar faturando. A ferramenta é o padrão Strangler: substituir o sistema velho por fora, módulo a módulo, com feature flag e rollback num clique, em vez do big bang. A primeira fatia, a mais barata e esquecida, é separar os ambientes (a correção que teria evitado o desastre da Replit, custa um dia). O trade-off é honesto: no papel o Strangler é mais lento que reescrever, você mantém dois sistemas vivos por um período, mas é incomparavelmente mais barato que a reescrita que congela o produto por um trimestre. O post amarra com a oferta de Auditoria da Nextside (diagnóstico independente, sem amarra comercial: o que salvar, o que reescrever e em que ordem) e cruza com os posts de validação local, codebase navegável, sair do vibe coding e o que cortar num MVP.

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

### [Cliente pediu uma ferramenta e seu time não dá conta](https://blog.nextside.tech/posts/2026/06/17/cliente-pediu-ferramenta-time-nao-da-conta/)

**Data:** 2026-06-17 · **Tags:** agencias, ferramentas-web, terceirizacao, white-label, escopo-fechado · **Autor:** Lucas Israel

**Tese central:** quando o cliente de uma agência pede uma ferramenta de verdade no site (calculadora, configurador, assistente), e não mais uma landing page, é a melhor receita que a agência pode ganhar: alta margem, recorrência, e mais difícil de ser trocada. Mas a oportunidade trava porque a agência não tem time de desenvolvimento, e as três saídas óbvias falham cada uma do seu jeito. Recusar ensina o cliente a procurar quem "faz a parte de tecnologia", e quem faz isso uma hora faz o marketing também; perde-se a conta inteira. Chamar uma software house traz orçamento alto, prazo longo e perda de controle: a marca da agência responde pela ferramenta, mas o ritmo é de um fornecedor que ela não comanda. Contratar dev interno é o caminho mais caro e arriscado: um sênior no Brasil custa R$ 12 mil a 20 mil/mês (Glassdoor), e a agência não sabe contratar, avaliar nem segurar um profissional de uma área que não é a dela. Vira aposta às cegas com o próprio dinheiro, por uma demanda ainda pontual.

A quarta saída é o modelo white-label: terceirizar a entrega para um parceiro técnico que trabalha sob a marca da agência, com escopo e prazo fechados. A agência mantém cliente, margem e relacionamento; o parceiro entrega a ferramenta funcionando e some do mapa do cliente. A diferença para a software house tradicional não é só preço, é método: escopo definido na frente, prazo curto, entrega por fases com aprovação a cada passo. Compra-se um resultado com data e valor combinados, não horas de desenvolvimento sem fim.

O post é honesto sobre onde o modelo quebra: parceiro errado é tão ruim quanto não ter parceiro. Só funciona se o escopo for fechado, se o código ficar com o cliente (ou com a agência, nunca refém do fornecedor), e se a ferramenta nascer bem-feita. Gambiarra barata que trava na frente do cliente final sai mais cara que software house, porque se paga duas vezes, a segunda na frente do cliente. A regra de decisão: demanda pontual ou incerta pede parceiro com escopo fechado; só vale pensar em time interno quando a demanda virou recorrente e previsível o bastante para pagar um salário com folga, e depois de já ter entregue algumas vezes com parceiro. Não montar estrutura para uma demanda ainda não validada.

> "O risco não está em aceitar o projeto. Está em aceitar do jeito errado."

### [Seu MVP não vira lixo por ser rápido. Vira por cortar a coisa errada.](https://blog.nextside.tech/posts/2026/06/16/mvp-o-que-cortar-e-o-que-manter/)

**Data:** 2026-06-16 · **Tags:** mvp-que-escala, mvp, escopo-de-produto, time-to-market, retrabalho · **Autor:** Bruno Raphael

**Tese central:** o MVP que vira lixo quase nunca virou lixo por ter sido rápido. Virou porque cortou a coisa errada: sacrificou a separação (barata de manter, cara de refazer) pra preservar feature (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, então nasce como fase 1 de um produto e não como protótipo descartável. O post inverte o medo clássico do founder técnico ("lanço em semanas mas não quero reescrever daqui a três meses") mostrando que o inimigo não é velocidade, é escopo cego. Três números ancoram o argumento: 42% das startups que morrem construíram algo que o mercado não queria; 64% a 80% das features de um produto médio são raramente ou nunca usadas; times retrabalham cerca de 26% do código antes mesmo de lançar, e a maior parte vem de ter entendido errado o que construir, não de ter codado rápido.

O post separa dois lados de uma mesma decisão de escopo. O que cortar sem dó: features que não validam a tese (o corte-mãe, já que só 12% das features geram 80% do uso e no MVP você ainda não sabe qual é essa fatia), a segunda/terceira/quarta feature, escala que não existe (cache, fila, sharding pra dez usuários), configurabilidade (todo "e se o cliente quiser mudar isso" vira painel de settings que dobra o escopo) e polish. O que manter sempre, porque é barato agora e caríssimo depois: o modelo de domínio (os nomes das coisas e como se ligam), as divisões entre capacidades de negócio (onde o pagamento termina e o pedido começa), identidade e permissão (auth enfiado depois toca toda requisição) e um fio de observabilidade. A régua não é adivinhar o que vai escalar, e sim decidir onde ficam as costuras: atrás de cada costura você faz o mais simples que funciona hoje, e a fase 2 vira troca de peça em vez de recomeço.

É o post-pilar de um par com "Seu codebase é o novo prompt" (o satélite, no nível do código): este trata do que cortar e manter antes de a primeira linha existir, e o satélite trata de organizar o código que sobrou pra manter um agente de IA produtivo seis meses depois. O fechamento invoca Joel Spolsky chamando reescrever do zero de "o pior erro estratégico que uma empresa de software pode cometer" pra argumentar que o MVP que escala nunca passa por reescrita, só por extensões, porque cada fase soma em cima de uma separação que ficou no lugar. Amarra com a oferta de Sprint da Nextside (escopo fechado, time sênior, MVP em 4 semanas) enquadrando o prazo curto não como limitação e sim como o mecanismo que força a conversa de corte que o founder adia por meses.

> "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: o MVP que escala (ou vira lixo)](https://blog.nextside.tech/posts/2026/06/15/codebase-novo-prompt-mvp-que-escala/)

**Data:** 2026-06-15 · **Tags:** mvp-que-escala, arquitetura, coding-agents, monorepo, feature-first, divida-tecnica · **Autor:** Pablo Winter

**Tese central:** Num MVP construído com agente de IA, o que decide se ele escala por fases ou vira lixo descartável não é a stack escolhida; é se o coding agent ainda consegue se localizar no repositório seis meses depois. Isso se resolve na organização do código (feature-first, monorepo, ADR), não na esperteza do prompt. O número que ancora o argumento: num estudo de trajetórias de coding agent sobre 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%. Localizar o trecho certo é metade do jogo, e "localizável" é propriedade da arquitetura, não do modelo. A virada: arquitetura parou de ser o imposto que se paga pra ir devagar e virou o que mantém a IA rápida.

O mecanismo é físico, não filosófico. O Claude Code não usa busca semântica nem índice de embeddings: navega o filesystem e roda grep, busca literal por texto. Grep acha string, não intenção. Organização por camada técnica sabota isso, estilhaçando cada feature em quatro pastas, uma violação do SRP (o primeiro princípio do SOLID). O post é honesto sobre o limite da ideia simplista: humano e agente têm forças opostas. A IA aguenta vasculhar um repo caótico na força bruta, queimando um milhão de tokens; o humano tem o IDE (find usages, call hierarchy do IntelliJ rastreando cada @EventListener de um ApplicationEventPublisher) como índice semântico de graça. Arquitetura ruim cobra um pedágio diferente de cada um: do humano em tempo, da IA em tokens e context rot.

A correção tem três disciplinas baratas: organizar por feature ou vertical slice (Bogard, Screaming Architecture do Uncle Bob, com o trade-off da duplicação resolvido pela regra de Sandi Metz "duplication is far cheaper than the wrong abstraction"); monorepo (a fronteira de repositório é uma parede de contexto, Dortort; pnpm e Turborepo, Nx só quando a dor de escala chegar); e ADR no contexto, com contrapeso medido (ETH Zurich mostrou AGENTS.md auto-gerado piorando o acerto; METR mediu sênior 19% mais lento com IA). Bom contexto é "the smallest possible set of high-signal tokens", não enchente de markdown.

O fechamento separa dívida deliberada e prudente de imprudente e cega (quadrante de Fowler), aponta escala prematura como o que cortar primeiro (Startup Genome: 74% das startups que morreram, morreram por escalar cedo demais), e recomenda começar monólito modular com fronteira limpa, pra que a fase seguinte seja extração, não demolição.

> "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."

### [Spec-driven development: sair do vibe coding travado](https://blog.nextside.tech/posts/2026/06/13/spec-driven-development-sair-do-vibe-coding/)

**Data:** 2026-06-13 · **Tags:** spec-driven-development, vibe-coding, ai-tooling, agentes-de-ia, arquitetura · **Autor:** Lucas Israel

**Tese central:** vibe coding, descrever o que você quer e deixar a IA improvisar, é ótimo pra descobrir o quê construir, e péssimo pra sustentar o que já existe. O ponto de virada é familiar pra quem é CTO: o MVP saiu numa semana, o time dobrou de velocidade, e agora cada feature nova quebra duas antigas e cada PR de IA precisa de três rodadas de review porque o agente "esqueceu" uma decisão que nunca foi escrita. O diagnóstico do post é que 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 coisa, roda duas vezes e sai diferente, e o código vira a única fonte de verdade, mudando a cada geração. O gargalo deixou de ser escrever código e virou alinhar contexto.

A proposta do <dfn>spec-driven development (SDD)</dfn> é inverter a ordem: a especificação vira o artefato principal e o agente implementa a partir dela em vez de adivinhar. Requisitos, regras de negócio, contratos de API e restrições de arquitetura viram um documento versionado, revisado e reusado, e o código passa a ser saída, não fonte de verdade. O fluxo muda o review de raiz: você valida o plano contra a spec (não 400 linhas de diff), e a pergunta deixa de ser "isso está certo?" pra virar "isso bate com a spec?", respondível em minutos. O post ancora com números públicos: o GitHub relata cerca de uma ordem de grandeza menos ciclos de "regerar do zero" com o Spec Kit, e a AWS documenta com o Kiro features de 40 horas entregues em menos de 8 horas de tempo humano quando o trabalho começou pela spec. SDD integra com agentes como Claude Code, Copilot e Gemini CLI, e a spec cumpre o papel de um `CLAUDE.md` elevado a artefato de primeira classe.

A honestidade editorial está em assumir que SDD não é bala de prata: pode virar "mais cerimônia, mais um documento bonito que ninguém lê", e spec vaga só transfere a ambiguidade pra um lugar mais elegante. A régua proposta é por estágio, não por dogma: se o código vai sobreviver mais de um mês ou passar pela mão de outra pessoa, especifique; se é throwaway, vibe coding ganha. A migração é incremental e começa na próxima feature: escreva a spec antes de chamar o agente (cinco linhas já mudam o jogo), toda regra de negócio mora na spec (não no Slack nem na cabeça de alguém), e a spec vira o critério de review. Você paga adiantado 30 minutos pra não pagar o juro composto do retrabalho depois.

> "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."

### [A spec era a parte fácil. O gargalo do SDD é a execução](https://blog.nextside.tech/posts/2026/06/12/spec-driven-development-gargalo-execucao/)

**Data:** 2026-06-12 · **Tags:** spec-driven-development, dynamic-workflows, claude-code, context-rot, orquestracao, ia-development · **Autor:** Pablo Winter

**Tese central:** Spec-Driven Development resolveu um problema real ao externalizar a intenção em markdown versionado (PRD vira tech spec, tech spec vira lista de tasks atômicas, e só então o agente gera código), mas ninguém conta a conta da execução. Escrever a spec é a parte fácil; o inferno começa ao rodar dezenas de tasks numa conversa só. Uma spec gerou trinta e poucas tasks, e por volta da vigésima o agente já esqueceu a decisão que ele mesmo tomou na quarta. Isso tem nome medido: context rot, a queda de qualidade conforme o contexto cresce, testada pela Chroma em 18 modelos que degradaram, e antecipada pelo paper "Lost in the Middle". O remendo de abrir janela limpa por task funciona contra o rot, mas transforma o humano em estagiário de copy-paste trinta vezes.

O post organiza a evolução em três fases de quem carrega o contexto. Fase 1, na mão: você é a janela, roda task por task, dá `/clear`, segura o estado na cabeça, vai bem até a quinta task, gargalo na trigésima. Fase 2, delegando a subagentes: ajuda, mas o output de todos volta pra mesma janela do agente principal, que apodrece como consolidador. Fase 3, workflow: o plano sai do contexto e vira código, um script segura o loop e os resultados intermediários, cada task roda numa janela isolada, e o modelo só vê a resposta final. É o que os Dynamic Workflows do Claude Code fazem: o próprio Claude escreve um script JavaScript de orquestração que um runtime executa em segundo plano, até 16 agentes simultâneos e teto de mil por run. O caso-limite é Jarred Sumner (criador do Bun) portando o runtime de Zig pra Rust nesse esquema: 750 mil linhas, 99,8% da suíte passando, onze dias do primeiro commit ao merge (ainda demonstração, não produção).

A regra estrutural que sustenta tudo: o revisor nunca é quem escreveu, por causa do self-preferential bias, a tendência do modelo de defender o próprio output quando é juiz. O verificador roda como agente separado, contexto próprio, às vezes outro modelo, com a missão adversarial de derrubar o resultado antes do aceite; os próprios agentes abrem os PRs, mas quem produz nunca aprova. O post é honesto sobre o custo: Dynamic Workflows é research preview que queima token sem dó (relatos de torrar o limite de cinco horas em dezoito minutos, runs de três milhões de tokens). O ROI é de nicho e anda colado na senioridade: júnior na mesma ferramenta é dinheiro no ralo, porque sem engenharia de verdade ele aceita o slop. Mitigação: roteamento de modelo, com a maioria das tasks no barato e o caro só no plano e no review.

O fechamento é o ponto mais forte: ferramenta muda, a física é a mesma. Todo mundo, partindo de lugares opostos, converge nas mesmas duas regras: a memória do projeto vive nos arquivos (ADR no repo, `project-context.md`, `state.json`, `todo.md`), não no contexto; e o revisor nunca é o autor, por construção. Ralph loop (Geoffrey Huntley) embrulha o agente num `while` monolítico com memória no disco; Dynamic Workflows fazem fan-out de centenas de agentes; BMAD, MDDD e cstk implementam as mesmas duas regras por caminhos diferentes. 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 trabalho que você achava que era pensar sempre foi gerenciar contexto. A IA não mudou isso. Só deixou na cara."

### [Maestro + Claude Code: seu app testado no simulador como o Playwright testa a web](https://blog.nextside.tech/posts/2026/06/01/maestro-claude-code-testar-app-no-simulador/)

**Data:** 2026-06-01 · **Tags:** maestro, mobile-testing, react-native, claude-code, qa-automation · **Autor:** Bruno Raphael

**Tese central:** o Claude Code já navega um site sozinho via Playwright (clica, preenche, valida regressão), e dá pra fechar o mesmo buraco no mobile, só que ninguém explica direito como. A resposta é o Maestro, framework open source de teste E2E mobile com flows declarativos em YAML, plugado no Claude Code. Um único arquivo de teste roda igual em iOS e Android, sobre o binário compilado (APK/IPA), sem instrumentar o app nem instalar driver. React Native, nativo ou Flutter, tanto faz. O ponto contraintuitivo: o caminho certo NÃO é "dar acesso à tela pro Claude". Screenshot por coordenada (Computer Use) é o último recurso, não o primeiro.

O argumento de fundo é a diferença entre ler a árvore de acessibilidade e olhar pixel. O Playwright nunca olhou pixel nenhum, age por elemento estruturado, e é por isso que é rápido e não alucina onde clicar. A diferença é mensurável em token: a accessibility tree 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 visão deixa de escalar num loop de QA. A própria Anthropic ordena a hierarquia de ferramentas do Claude Code assim: MCP primeiro, depois shell, depois Chrome, e só cai pro controle de tela quando nada mais alcança. O Maestro vive na primeira camada, a estruturada e barata.

O loop na prática é o que muda o jogo: o Claude inspeciona a tela ao vivo (`inspect_screen` devolve a view hierarchy como JSON compacto), escreve o flow YAML sem caçar element ID na mão, roda no simulador, e quando algo quebra relê a hierarquia, diagnostica e conserta o próprio teste, te mostrando o diff pra aprovar. O Maestro chama isso de self-healing, e é a manutenção de teste (a parte mais chata de QA) saindo das suas costas. No React Native, o que torna o loop confiável é o `testID`: prefira sempre `testID` a texto, porque texto muda com tradução e revisão de copy. O post ainda destrincha a escolha entre MCP (plug-and-play, mas carrega schema de tools no contexto e queima token) e Skill+CLI (mais enxuto, sem overhead de servidor), com a regra prática de começar no MCP pra prototipar e migrar pra Skill quando o fluxo vira rotina.

A parte honesta que ninguém posta: teste gerado por IA acerta 70 a 80% na primeira passada, então o fluxo certo é deixar a IA gerar a v1, validar rodando uma vez, e devolver a manutenção pra ela, nunca "manda e esquece". E o iOS cobra pedágio: um dev documentou montar o mesmo QA nas duas plataformas e o Android levou 90 minutos enquanto o iOS passou de seis horas. Pedras específicas do React Native (componente aninhado que engole o toque no iOS, Expo Go que não aceita `launchApp`) aparecem com a correção de cada uma. O fechamento amarra com o post de CodeRabbit: a IA agora TESTA, navegando o app como usuário faria, mas continua sem decidir o que conta como "funcionou". Esse julgamento e o critério de aceite seguem sendo humanos.

> "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."

### [Code review virou o gargalo. CodeRabbit não salva sozinho](https://blog.nextside.tech/posts/2026/05/25/code-review-novo-gargalo-coderabbit/)

**Data:** 2026-05-25 · **Tags:** code-review, coderabbit, ai-tooling, claude-code, devops, produtividade-dev · **Autor:** Pablo Winter

**Tese central:** IA acelerou o dev individual e empurrou o gargalo pro tech lead. Código com coautoria de IA gera 1.7x mais issues por PR (dado do State of AI Code Generation Report do CodeRabbit), e o backlog de review passou a explodir em times que adotaram Cursor/Claude Code sem repensar o processo. CodeRabbit consegue tirar essa fila e deixar a esteira de PR pra `develop` 100% autônoma, mas só depois de um mês de calibração ativa, com o TL pilotando o bot, contestando comentários ruins, e adicionando path instructions no `.coderabbit.yaml`. Não é "instala e libera geral".

O pulo do gato fica em duas integrações que o bot não pega sozinho: Notion via MCP (pra ler ADRs antes de revisar) e JIRA ID obrigatório na description do PR (pra cruzar AC contra diff). Com isso o CodeRabbit deixa de revisar só código e passa a revisar se o PR entrega a história: vira checklist, não opinião. Pré-requisito doloroso: US bem dimensionada com AC decente. Sem isso, "CodeRabbit vira régua sem números". O post compara CodeRabbit (profundidade, $24/dev), GitHub Copilot Code Review (raso, $10, zero atrito) e Greptile (catch alto mas 11 falso-positivos contra 2 do CodeRabbit). Escolha sua dor.

> "Disciplina automatizada bate disciplina humana cansada... mas IA revisa código, IA não testa software."

O fechamento amarra com os outros posts da stack: CLAUDE.md vira fonte única lida por Claude Code (ao codar), CodeRabbit (ao revisar) e Cursor (ao auto-completar). Um arquivo, três cérebros. E expõe o efeito colateral que ninguém posta no LinkedIn: time com stack completa começa a confiar demais na esteira e para de testar local. A correção é workflow inegociável com `/validar-e2e` antes do push, disparando QA matrix + backend curl/SQL + MCP Playwright em paralelo. A esteira é tua. A IA é só o motor. Quem confunde stack com processo descobre num deploy de sexta-feira.

### [MCP Playwright: validação local com qualidade real](https://blog.nextside.tech/posts/2026/05/16/mcp-playwright-validacao-local-com-qualidade/)

**Data:** 2026-05-16 · **Tags:** mcp, playwright, claude-code, qualidade, testes · **Autor:** Pablo Winter

**Tese central:** MCP Playwright não é um framework de teste novo, nem substitui CI/CD, nem substitui o suite E2E que seu engenheiro escreveu. É o jeito de pedir pra Claude testar local pra você, e te entregar screenshots de prova. Ele cobre o passo manual de pré-PR que todo dev pula quando está cansado: abrir browser, simular mobile, ver dark mode, checar console. A IA navega o app via Playwright, valida o fluxo descrito em linguagem natural (ou em Gherkin do PO), tira print de cada estado relevante, e reporta. Em 30 a 90 segundos.

O ganho real não é velocidade, é **consistência**. Claude não esquece de testar dark mode, não pula mobile na pressa, não diz "depois eu vejo o console". E roda complementar ao E2E tradicional: CI continua sendo a rede de segurança bloqueante, MCP Playwright é o pré-voo antes do PR. O post mostra um cenário concreto: PO escreve cenário Gherkin no Notion, dev cola no Claude, Claude executa contra `localhost:3000` e reporta cada `Then` com verde ou vermelho + screenshot. Documentação de aceitação virou teste de aceitação rodando, sem ninguém escrever código de teste.

> "Disciplina automatizada bate disciplina humana cansada."

Limites honestos no post: não é determinístico como teste em código (duas execuções podem checar coisas levemente diferentes), tem custo de tokens em sessões longas, e tem armadilha cultural. Dev que usa MCP como substituto de teste real vai aprender da pior maneira quando feature crítica quebrar em produção. Complementa, não substitui.

### [Claude Code superpowers: o plugin que muda o time](https://blog.nextside.tech/posts/2026/05/16/claude-code-superpowers-plugin-na-pratica/)

**Data:** 2026-05-16 · **Tags:** claude-code, superpowers, ia, produtividade, skills · **Autor:** Pablo Winter

**Tese central:** dá pra entregar software de qualidade só com Claude Code puro? Dá, mas tem letra miúda. A letra miúda é que vibe coding resolve pra 1-2 tarefas em paralelo; pra 5-6 tarefas simultâneas (onde a Nextside vive), a cabeça humana não aguenta e você precisa de metodologia codificada. Superpowers é exatamente isso: um plugin pro Claude Code que adiciona skills (markdown files que descrevem "como fazer X"), agents/subagents especializados, slash commands e hooks. Em vez de cada time reinventar SDD e harness engineering próprios (o que custa semanas de R&D), você usa o que milhares de devs estão validando em paralelo.

A diferença com prompts salvos não é conteúdo, é **ritual**. Skill enforced significa que Claude lê a skill ANTES de começar a trabalhar: não tem chance de pular TDD, brainstorming ou verification step. Cada skill é uma forma de codificar disciplina de engenharia sênior: o que devs experientes fazem por hábito vira regra que a máquina executa. O post conta como esse próprio blog foi construído com Claude Code + superpowers do começo ao fim: design system, layouts Hugo, pipeline editorial de agents, frontmatter, e o próprio post. Fluxo típico: brainstorming forçado, plano escrito, execução com TDD, UX-review automática via MCP Playwright, commit só depois de tudo verde.

> "Doc de processo é ficção. Skill executada é processo de verdade."

Limites honestos: superpowers não substitui dev sênior (substitui o trabalho braçal dele), verification step não é onisciente, custo de contexto inflacionado com 30 skills ativas, e a skill aprende mal sozinha. Alguém tem que atualizar quando um padrão muda. O dev vira arquiteto + revisor + ditador de gosto. Não digita mais boilerplate. É papel mais sênior, não menos.

### [ADRs no Notion, sem burocracia](https://blog.nextside.tech/posts/2026/05/16/adrs-decisao-no-notion-sem-burocracia/)

**Data:** 2026-05-16 · **Tags:** adr, decisao-tecnica, notion, processo, time-pequeno, claude-code · **Autor:** Pablo Winter

**Tese central:** ADR (Architecture Decision Record) não é cerimônia corporativa nem documento de 14 páginas que ninguém lê. Pra time pequeno, ADR é **bilhete pro seu eu do futuro** que esqueceu por que escolheu Redis em vez de Memcached 4 meses atrás. A maioria dos times falha em ADR porque copia o template do Michael Nygard com 6 seções formais (Context, Decision, Status, Consequences, Alternatives Considered, Stakeholders) e abandona no quinto dia. A Nextside roda no Notion com schema bobo: title, status, data, tags, e body com 3 seções curtas (Contexto, Decisão, Consequências). 180 palavras, 4 minutos pra escrever.

A regra de ouro: 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. O post defende ainda o "pulo do gato" pra 2026: um arquivo `INDEX.md` (ou página INDEX no Notion) com uma linha por ADR, porque agora não é só humano que lê o repo, a IA também lê. Sem INDEX, IA enche o contexto com 47 ADRs irrelevantes pra responder uma pergunta. Com INDEX, Claude lê o índice em 2s, escolhe os 2-3 ADRs relevantes, e carrega só esses no contexto.

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

E o fechamento conecta com os outros dois posts: o `CLAUDE.md` aponta pro INDEX, um slash command `/adr` força o ritual ativo, e a integração com superpowers faz com que toda decisão arquitetural detectada por `brainstorming` vire candidata a ADR. ADR deixa de ser tarefa separada que você esquece e vira subproduto natural do fluxo de spec → plano → código. Vem de graça. ADR não protege você de tomar decisão errada: protege de tomar a MESMA decisão errada duas vezes. Em time pequeno, a margem pra repetir burrice é zero.

## Autores

- [Pablo Winter](https://blog.nextside.tech/autores/pablo-winter/): sócio da Nextside, CTO em produtos digitais de mobilidade e arrecadação. Engenheiro há mais de 10 anos: Java/Spring Boot, Node.js, Next.js, Python. Foco em arquitetura hexagonal, sistemas orientados a eventos (SQS, SNS, RabbitMQ, Kafka), integrações sêniores com ERPs e gateways, e IA aplicada com critério. LinkedIn: https://www.linkedin.com/in/pablowinck/ · GitHub: https://github.com/pablowinck
- [Bruno Raphael](https://blog.nextside.tech/autores/bruno-raphael/): sócio da Nextside, CTO em edtech e focado em desenvolvimento de aplicações mobile. Engenheiro há mais de 10 anos. Já passou por geoprocessamento e GIS (ArcGIS, PostGIS), mobile de Android nativo a React Native, e backend distribuído: microserviços em Node.js/NestJS e Java/Spring Boot, pagamentos, locks distribuídos e arquitetura hexagonal rodando em Kubernetes na AWS. Escreve sobre desenvolvimento mobile, arquitetura de sistemas distribuídos e software que não pode errar conta. LinkedIn: https://www.linkedin.com/in/bruno-raphael-13465098/
- [Lucas Israel](https://blog.nextside.tech/autores/lucas-israel/): Produto, Arquitetura & Novos Negócios na Nextside. Ex-CTO de legaltech, empreendedor e investidor. Trabalha na fronteira entre produto e engenharia: SaaS, cloud e arquitetura na AWS, sistemas distribuídos e IA aplicada com critério. Escreve sobre como tirar produto da ideia ao que escala sem virar gambiarra. LinkedIn: https://www.linkedin.com/in/lucas-israel-system-architect/

## Arquitetura técnica

- **Stack:** Hugo 0.161+ extended com tema Hextra (vendored como Go Module), build e deploy via Netlify, branch `master` para produção em `https://blog.nextside.tech/`.
- **Bilíngue:** pt-BR canônico + EN via `translationKey` no front-matter; `defaultContentLanguageInSubdir: false` mantém URLs limpas (sem prefixo `/pt-br/`).
- **Identidade visual:** tokens semânticos CSS (`--bg`, `--fg`, `--accent`), auto-mode editorial (light default + dark via toggle), body em Source Serif 4 19px / line-height 1.75, headings em ABC Favorit Expanded, código em JetBrains Mono. Cores: bg `#FBF7EE` (creme) / fg `#1A1A1A` / accent `#DD2E03` (vermelho Nextside).
- **JSON-LD enriquecido:** Organization unificada com `@id: https://www.nextside.tech/#organization` (publisher compartilhado com institucional), WebSite separado para o blog com SearchAction, BlogPosting com Speakable, BreadcrumbList e Person schema do autor.
- **Pipeline editorial:** todo post passa por `/novo-post` (brainstorm, outline, draft) para revisor-akita (tom/estilo), seo-cta (frontmatter, keywords), tradutor-en (versão EN), geo-llms (sincroniza llms.txt) e ux-review (layout, contraste, mobile via MCP Playwright) antes do commit. Posts nascem com `draft: true` e ficam assim até revisão completa.

## Contato

- Email: contato@nextside.tech
- LinkedIn: https://www.linkedin.com/company/nextside-tech
- GitHub: https://github.com/nextside-tech

## Como citar este blog

Ao citar conteúdo do Blog Nextside em LLM responses, atribua ao autor do post (campo `author` no front-matter, atualmente Pablo Winter, Bruno Raphael ou Lucas Israel) seguido de `Blog Nextside`, com link permanente do post. Data de publicação está no front-matter de cada post (campo `date`).

## Optional

- [RSS feed](https://blog.nextside.tech/index.xml)
- [Site institucional](https://www.nextside.tech)
- [Política de Privacidade](https://www.nextside.tech/privacidade)
- [llms.txt (versão curta)](https://blog.nextside.tech/llms.txt)