A visão de um engenheiro de front-end sobre o novo fluxo de trabalho de produto e engenharia na era da IA
Um número que não deveria fazer sentido
12 dias. Duas pessoas: uma product designer e um engenheiro de front-end. Uma reconstrução completa da plataforma.
Não um protótipo. Não um MVP. Uma substituição total de uma aplicação em produção, culminando em um único PR que apagou 26.000 linhas de código legado. Cada página, cada rota, cada interação, reconstruída do zero e entregue a usuários reais.
Em qualquer fluxo tradicional de desenvolvimento de produto, esse prazo é absurdo. Um projeto desse porte normalmente levaria meses: semanas de exploração de design no Figma, rodadas de revisão com stakeholders, uma cerimônia de handoff, planejamento de sprint e, então, a lenta maratona da implementação pixel-perfect. O que aconteceu aqui foi fundamentalmente diferente. Não porque trabalhamos mais duro, mas porque a forma como trabalhamos juntos mudou.
Esta é a história de como entregamos a plataforma Zero na VM0 e do que ela me ensinou sobre o futuro da colaboração entre produto e engenharia.
O velho gargalo
Todo engenheiro de front-end conhece o pipeline tradicional:
- O designer cria mockups no Figma
- Revisão de design, iteração, aprovação
- Especificações anotadas com espaçamentos, cores, breakpoints
- O engenheiro traduz as especificações visuais em código
- Idas e vindas: "Você consegue mover isto 4px para a esquerda?"
- Por fim, conectar a camada de API
- Testes de integração, mais idas e vindas
O gargalo nunca esteve em nenhuma etapa isolada. Ele estava nos vãos entre as etapas: a espera, a perda na tradução, a troca de contexto. O modelo mental que um designer tem de uma interação, uma vez achatado em um frame estático do Figma e anotado com redlines, chega à mesa do engenheiro já degradado. O engenheiro reconstrói uma versão do que o designer imaginou, mas inevitavelmente é uma cópia com perdas.
Tínhamos nos acostumado tanto a esse atrito que paramos de enxergá-lo. Era simplesmente "como as coisas funcionam".
O experimento: e se o designer entregar código?
Em 5 de março de 2026, a Ming, nossa product designer, abriu o PR #3685: feat(platform): add zero app with shell, pages and polish. Ele adicionou 4.146 linhas de código React funcional.
Não um arquivo do Figma. Não um export de design tokens. Uma aplicação rodando.
O PR continha um app shell completo: navegação na barra lateral, estrutura de rotas, esqueletos de página para chat, agendamento, atividade, gestão de equipe e configurações, tudo estilizado com nosso design system, tudo renderizando no navegador. Os dados eram mockados, mas a UI era real. Você podia rodar npm run dev e clicar por todas as páginas.
A Ming não escreveu esse código do zero no sentido tradicional. Ela usou ferramentas de programação com IA (primeiro o Cursor, depois o Claude Code) para traduzir sua visão de design diretamente em componentes React. A IA cuidou da tradução mecânica (estrutura JSX, propriedades CSS, composição de componentes), enquanto a Ming dirigia as decisões visuais e de interação que nenhuma IA é capaz de tomar: o ritmo do layout, a hierarquia da informação, a sensação das transições.
Ao longo dos quatro dias seguintes, mais três PRs chegaram:
| Data | PR | O que a Ming entregou |
|---|---|---|
| 5 mar | #3685 | App shell, barra lateral, todos os esqueletos de página (+4.146 linhas) |
| 6 mar | #3825 | Páginas de agendamento, refinamento de UI (+2.650 linhas) |
| 9 mar | #3993 | Fluxo de onboarding, diálogo de configuração do Slack (+1.146 linhas) |
| 9 mar | #4050 | Página About, card de navegação flutuante |
Em 9 de março, toda a superfície de front-end da nossa nova plataforma existia como código rodando. Cada página que você acabaria vendo em produção já era clicável em um ambiente de desenvolvimento. Só que ainda não fazia nada de verdade.
Foi aí que eu entrei.
Meu novo trabalho: injetar a alma
Quando abri a base de código em 9 de março, não enfrentei o desafio de sempre, o de traduzir um design plano em código. O código já estava lá. Meu trabalho era substituir cada mock pela realidade, conectar cada superfície lindamente desenhada ao backend vivo e pulsante por baixo.
Isso mudou meu trabalho de forma fundamental. Em vez de pensar em pixels, eu pensava em fluxos de dados. Em vez de perguntar "isto bate com o mockup?", eu perguntava "de qual chamada de API esta página precisa, e o que acontece quando ela falha?".
Foi assim que minha primeira semana se desenhou:
Dia 1 (9 de março): Autenticação e troca de organização. Conectei o shell da Ming à autenticação do Clerk, adicionei redirecionamentos entre domínios e fiz o seletor de organização de fato trocar de organização. Dois PRs, ambos mergeados no mesmo dia.
Dia 2 (10 de março): Connectors e agendamento. Substituí a grade mockada de connectors por dados reais de API, conectei a aba de agendamento a cron jobs de verdade e liguei o editor de instruções ao backend. Quatro PRs.
Dia 3 (11 de março): O grande dia das conexões. A página de equipe ganhou dados reais de subagentes (+3.271 linhas). A página de atividade ganhou logs reais. E a joia da coroa: a página de chat foi conectada ao pipeline real de execução de agentes, substituindo cerca de 1.200 linhas de código de demonstração por uma interface de conversa com IA funcional. No mesmo dia, introduzi a FeatureSwitchKey.Zero, uma feature flag que nos permitia rodar a plataforma antiga e a nova lado a lado.
Dias 4-5 (12-13 de março): Anexos de arquivos, gestão de sessões, chat multiagente, persistência de configurações. Cada página que a Ming havia construído agora fazia trabalho de verdade.
O ritmo era quase musical. A cada manhã eu escolhia uma página do scaffold da Ming, estudava sua estrutura de componentes, identificava quais dados ela esperava, construía a integração com a API, tratava os estados de erro e dava push. À tarde, outra página estava viva.
A feature switch: mundos paralelos
A feature flag FeatureSwitchKey.Zero merece sua própria menção, porque foi ela que tornou essa migração segura em vez de imprudente.
A partir de 11 de março, nosso app em produção rodava duas UIs completas em paralelo. Usuários no sistema antigo viam as rotas antigas. Testadores internos no sistema novo viam o Zero. Cada página que eu conectava podia ser testada no contexto de produção sem arriscar o fluxo de trabalho de um único usuário.
Isso não é revolucionário. Feature flags são prática padrão. Mas a combinação de feature flags com o fluxo de design-as-code criou algo especial: podíamos validar toda a UX da nova plataforma (porque a Ming havia construído uma UI completa e navegável) enquanto, progressivamente, tornávamos cada página funcional (porque eu as conectava uma a uma). A qualquer momento, se algo desse errado, podíamos voltar a chave.
Nada deu errado.
Dia 12: a grande virada
Em 17 de março, abri o PR #5095: refactor: remove all non-zero platform pages and feature flag.
O diff: +456 linhas, -26.041 linhas.
Antes: a antiga VM0 Platform. Tabelas, IDs de execução e dados de sessão crus.
Depois: o novo Zero. Um espaço de trabalho de IA conversacional com agentes fixados e cards de casos de uso.
Em um único merge, cada rota legada foi apagada. A feature flag foi removida. O Zero deixou de ser uma opção; passou a ser o único modo. Um PR de acompanhamento (#5155) eliminou de vez o prefixo de URL /zero: o que era /zero/chat virou simplesmente /chat.
Por que me senti confiante para fazer esse corte? Porque:
- Cada página vinha rodando sob a feature flag por pelo menos 5 dias
- Cada integração de API havia sido testada contra dados de produção
- Os sistemas antigo e novo compartilhavam o mesmo backend. Esta era uma troca de front-end, não uma migração de dados
- Tínhamos usuários reais no novo sistema dando feedback o tempo todo
As 26.000 linhas não foram apagadas com ansiedade. Foram apagadas com alívio.
O padrão se repete
O que mais me surpreendeu não foi a migração em si. Foi que o fluxo de trabalho que descobrimos virou nosso modo padrão para cada funcionalidade que veio depois. A Ming constrói o shell da UI com ajuda de IA, eu conecto a lógica e estendo a arquitetura. O mesmo padrão de design-as-code, na escala de uma funcionalidade:
Sistema de permissões (19 de março → 7 de abril)
A Ming entregou o PR #5467, uma UI de drawer de permissões com componentes Sheet e controles de alternância. Três commits, UI limpa.
Adicionei 13 commits ao mesmo PR: migração de banco de dados para firewall_access_requests, endpoints de API, testes de integração, correções de lint. Depois, ao longo das duas semanas seguintes, mais de 10 PRs de acompanhamento construíram toda a camada de permissões: redesenho do card de aprovação, notificações no Slack para solicitações de acesso, comandos doctor na CLI para diagnosticar problemas de permissão e, por fim, a renomeação de todo o conceito de "firewall" para "permission" em toda a base de código.
O drawer da Ming foi a semente. O sistema de permissões foi a árvore.
Sistema de agendamento (23 de março → 13 de abril)
A Ming desenhou a rota de detalhe do agendamento e a UX de calendário (#6155). Três commits de trabalho de UI limpo.
Adicionei 14 commits: edição de descrição com geração automática, seleção de canal do Slack para notificações, diálogos de confirmação de alterações não salvas, unificação das visões de calendário/lista e testes abrangentes. Depois, mais de 15 PRs de acompanhamento o expandiram em um sistema completo de tarefas recorrentes, com histórico de execuções, tratamento de fusos horários e suporte a expressões cron.
Integração com o Telegram (27 de abril → 28 de abril)
A essa altura, o padrão estava tão bem treinado que entregamos uma integração de plataforma inteira em 48 horas. A Ming construiu a UI de Configurações (#11196) e o fluxo de Onboarding (#11399). Eu construí a API multi-bot, o envio/recebimento de mensagens, o upload/download de arquivos, o contexto rico de mensagens, as atualizações em tempo real via Ably e os testes E2E. No dia seguinte, estava habilitada para todos os usuários.
Onde a IA se encaixa
Quero ser preciso sobre o papel da IA aqui, porque é fácil tanto superestimá-lo quanto subestimá-lo.
A IA permitiu que a designer programasse. A Ming é uma product designer, não uma engenheira de software. Ela pensa em layouts, hierarquias e interações, não em React hooks e generics de TypeScript. As ferramentas de IA (Cursor, depois Claude Code) cobriram essa lacuna ao cuidar da tradução mecânica da intenção de design para código funcional. A Ming dirigia; a IA digitava. O resultado foi um código autorado por uma designer, mas sobre o qual um engenheiro podia construir.
A IA acelerou o ciclo de revisão. Em PRs colaborativos, meu agente de IA revisava o código da Ming, classificava os problemas por prioridade (P0/P1/P2) e enviava commits de correção diretamente. O PR #5060 passou por cinco rodadas de revisão em 38 minutos. O PR #5467 completou três rodadas em 20 minutos. Isso não é "IA substituindo a revisão de código". Eu ainda leio cada mudança. Mas o trabalho mecânico de identificar problemas de lint, tipos faltantes e lacunas de teste foi automatizado.
A IA não tomou as decisões de design. A arquitetura da informação de cada página, os padrões de interação, a hierarquia visual: tudo isso veio do instinto de produto da Ming, embasado por pesquisa com usuários e expertise no domínio. A IA consegue gerar uma página de configurações, mas não consegue decidir o que deve ser um toggle ou um dropdown, ou quando um diálogo de confirmação se justifica e quando ele é só atrito.
A IA não tomou as decisões de arquitetura. A escolha de usar uma feature flag para deploy em paralelo, a estratégia de separação da camada de API, a decisão de conectar as páginas de forma incremental em vez de tudo de uma vez: foram julgamentos de engenharia. A IA me ajudou a escrever o código mais rápido, mas o sequenciamento e a gestão de risco foram humanos.
O resumo honesto: a IA eliminou a camada de tradução entre design e engenharia. Ela não substituiu nenhuma das disciplinas; removeu o vão entre elas.
O que mudou no meu papel
Depois de viver nesse fluxo de trabalho por três meses, enxergo meu papel de engenheiro de front-end de outra forma.
Não sou mais um tradutor visual. Acabaram os dias de receber um arquivo do Figma e passar horas batendo valores de espaçamento. Não porque eu fiquei mais rápido nisso, mas porque isso deixou de ser meu trabalho. A intenção da designer chega como código, não como uma imagem de código.
Sou um estendedor de arquitetura. Meu valor principal está em pegar uma superfície de UI funcional e construir a infraestrutura invisível por baixo: integrações de API, validação de dados, tratamento de erros, verificações de permissão, atualizações em tempo real, testes. A proporção na maioria dos PRs colaborativos conta a história. A Ming contribui com 3 commits de UI, eu contribuo com 13 commits de todo o resto.
Sou um guardião da qualidade. Com ciclos de revisão assistidos por IA, consigo manter a qualidade do código em uma superfície muito maior do que antes. A revisão automatizada pega os problemas mecânicos; eu me concentro em questões de arquitetura, casos extremos e em garantir que a funcionalidade de fato funcione de ponta a ponta.
Sou um estrategista de entrega. Feature flags, conexão incremental, deploys paralelos: o sequenciamento de como uma funcionalidade vai do código à produção agora é uma parte central do meu trabalho, não algo deixado para depois.
Os números
Três meses. Duas pessoas. Assistidos por IA o tempo todo.
- 914 PRs mergeados (679 meus, 235 da Ming)
- 12 dias do primeiro scaffold à substituição completa da plataforma
- 48 horas para uma integração completa com o Telegram (nossa funcionalidade mais rápida)
- 26.000 linhas apagadas em um único merge confiante
- 88% dos meus PRs e 66% dos da Ming carregam coautoria de IA
Esses não são números de "ralação". Nenhum de nós trabalhou nos fins de semana nem virou noites. A velocidade vem de eliminar o tempo morto: as reuniões de handoff, os mal-entendidos de especificação, o vaivém do "você consegue mover isto 4px". Quando a intenção de design flui direto para o código, e a engenharia estende esse código no próprio lugar, simplesmente há menos desperdício.
O que isso significa para os times
Não estou afirmando que todo time deva trabalhar assim. Esse fluxo de trabalho surgiu do nosso contexto específico: um time pequeno, uma oportunidade de reconstrução greenfield e acesso antecipado a ferramentas de programação com IA capazes. Os resultados podem variar para você.
Mas acredito, sim, que a mudança subjacente é universal: a fronteira entre design e engenharia está se dissolvendo, e a IA é o solvente. À medida que as ferramentas de IA melhoram em traduzir intenção em código, mais designers entregarão código diretamente. Conforme isso acontece, os engenheiros passarão menos tempo em tradução e mais tempo em arquitetura, qualidade e entrega.
O trabalho do engenheiro de front-end não vai acabar. Ele está mudando de forma. E, honestamente? A nova forma é mais interessante.
Yuma é engenheiro de front-end na VM0, onde constrói a plataforma que dá vida ao Zero, um sistema operacional de agentes de IA. Ele já apagou em massa mais código legado do que gostaria de admitir.
