Implementação

01010101

.Implementação

O Parity é o processo da deco para migrar e modernizar lojas com agentes de IA. Com ele, a Ri Happy trocou de stack em 12 dias úteis e a FILA foi do Figma ao ar em menos de um mês.

Desenvolvido pelo Jonas Jesus, engenheiro da deco, o Parity reúne duas peças.

• Um plugin do Claude Code, com um orquestrador e 20 agentes.
• A parity, uma linha de comando que mede se a loja nova ficou igual à antiga.

Origem, destino e guardrails

Todo ciclo de implementação começa por uma origem, e ela muda a cada projeto. Na FILA, era o layout no Figma, e os agentes construíram a loja a partir das telas desenhadas. Na Ri Happy, era o repositório da loja em VTEX IO. Também já testamos rodar o Parity a partir de um site público no ar, sem termos acesso ao repositório. Nesse último caso, o Parity faz a engenharia reversa do que a web expõe (páginas, endpoints, sistemas conectados, tags do GTM) e remonta o mapa da loja.

Quem faz essa leitura é o parity capture. Ele percorre a loja e registra tudo o que o cliente vê, das cores e fontes aos espaçamentos, ícones e imagens, e salva cada componente com o seu HTML e uma captura de tela. Quando tem o repositório, o Parity confere o que leu contra o código. Sem acesso ao repositório, o trabalho exige de três a cinco vezes mais rodadas de correção (mais tokens), por isso o Parity solicita o acesso antes de seguir.

Com a origem configurada, declaramos o destino: a loja nova, o output da implementação. No caso da FILA e da Ri Happy, foi a FastStore v4. No caso da FARM, foi o TanStack, a stack mais recente da deco.

Entre a origem e o destino, definimos os guardrails, ou seja, os pontos que precisam ser preservados durante a implementação. Por exemplo:

• O motor de busca.
• A plataforma de commerce.
• Os componentes customizados criados.
• A implementação do GTM e o tracking de dados.

Os checks do Parity conferem cada um desses pontos entre a origem e o destino.

O plano

No kanban de Execução do deco Studio, cada página vira um card. O agente PM escreve a spec, move o que entra em execução e, quando o card passa no QA, leva-o para produção. Os comentários que o PM faz em cada card viram instrução para o agente de execução.

A execução

Quem implementa o código de cada card é o Claude Code, uma instância por sandbox. Como um computador comum sustenta poucas tarefas em paralelo, a deco mantém uma máquina dedicada à execução. Nela, um agente reescreve os componentes, outro deixa o build verde e outro corrige uma diferença por pull request.

Antes do merge, cada pull request passa por revisão de código e QA no preview, e o que mexe em login, carrinho ou checkout passa também pela nossa verificação de segurança.

Os checks

Quando todos os cards foram implementados, o agente PM navega na loja que foi construída, compara-a com a origem e abre um card para cada pendência verificada. Cada página recebe uma nota de paridade de 0 a 100, recalculada a cada commit. A nota é fruto de 45 checks realizados nas duas lojas, que passam por:

• A jornada de compra, da busca e da vitrine ao produto e ao carrinho.
• O checkout até a escolha do Pix, onde o Parity navega sem fechar pedido.
• SEO, velocidade, console, rede e cache.

A primeira passada costuma já passar com algo entre 85 e 90 de paridade, mas o ciclo agêntico só é interrompido para o ser humano atuar quando passa da nota 97 de 100.

Para times que exigem paridade pixel a pixel, existe o Comparador Visual, que construímos para a Oficina. Ele sobrepõe a página nova à original e pinta de vermelho tudo o que diverge, sem tolerância. Cada mancha vira uma instrução para o agente, como "o botão ficou 18 px mais baixo", e a página é medida de novo até não restar nenhuma divergência de UX, pixel a pixel.

A revisão humana

Com a nota acima de 97, os engenheiros humanos da deco recebem o site com cerca de 90% pronto e começam o teste manual em navegadores, sistemas e resoluções diferentes, conferindo o GTM, o tracking de dados, cada integração e cada customização.

O go-live

Com as aprovações, a loja nova entra no ar em um rollout progressivo. Primeiro 1% do tráfego vai para ela, depois 5, 10, 25, 50 e 100%. Para subir um degrau, a versão nova precisa vender e converter pelo menos como a antiga, na proporção do tráfego que recebe. Quando o resultado fica abaixo, a equipe investiga e corrige antes de avançar.

Os resultados

dias úteis para trocar de stack

A Ri Happy migrou como estava. As 1.200 páginas e 11 customizações saíram do VTEX IO para a FastStore v4 em 12 dias úteis, do kickoff, em 17 de setembro, à virada, na madrugada de 6 de outubro. Na mesma semana, a loja nova já recebia todo o tráfego.

no PageSpeed mobile

A FILA aproveitou a migração para trocar de cara, e dois engenheiros da deco e os agentes reconstruíram a loja a partir do Figma em menos de um mês. O PageSpeed no celular foi de 70 para 95, com nota máxima em acessibilidade, boas práticas e SEO.

O Parity ilustra o modo como a deco opera, com agentes que planejam, executam e verificam o trabalho uns dos outros em ciclos fechados. Fora do Brasil, esse método é popularmente conhecido como loop engineering e, quando aplicado à operação inteira, como software factory. O tema está em Software Factories e na palestra do Gui Rodrigues, co-founder e CEO da deco, sobre loops de agentes.