OpenAI coloca um frontend alojado por detrás do Codex com Sites, anotações e um plugin de design de produto

O Sites transforma o output do Codex numa superfície web alojada e partilhável

A parte mais relevante desta atualização para o frontend é o Sites, em pré-visualização para clientes Business e Enterprise. O Codex pode agora gerar páginas web interativas e alojadas — dashboards, planeadores, espaços de revisão, quadros de projeto, galerias — e partilhá-las num workspace através de um URL. Trata-se de uma mudança significativa para uma ferramenta que começou como assistente de desenvolvimento de software: o entregável já não é um ficheiro ou um diff de código, mas sim uma página em funcionamento que outra pessoa pode abrir e com a qual pode interagir.

Os Sites são um novo tipo de tela para as suas ideias.Montana Labs

Os exemplos são concretos: um site para uma revisão de cliente montado a partir de atualizações de produto, questões em aberto e tendências de utilização; um planeador de cenários construído a partir de um modelo financeiro para que os líderes comparem pressupostos em vez de lerem separadores de folhas de cálculo. A OpenAI sublinha ainda que estas páginas não são estáticas e que o Codex pode mantê-las atualizadas à medida que os detalhes mudam — posicionando o Sites como superfícies de aplicações vivas, e não como exportações pontuais.

A lista de parceiros lê-se como um mapa da concorrência

A OpenAI nomeia parceiros iniciais do Sites, incluindo Vercel, Wix, Base44, Replit, Lovable, Figma, Webflow e Emergent. Esta lista é notável porque a maioria destes nomes está, ela própria, no negócio de transformar intenção em frontends implementados. Ao apresentá-los como parceiros de um 'ecossistema de parceiros de sites', a OpenAI dá a entender que quer posicionar-se acima da camada de alojamento e construção de páginas, em vez de se limitar a alimentá-la com código.

Para as equipas que constroem sobre qualquer uma destas plataformas, a questão prática é onde fica a fronteira da geração: se o Codex produz o frontend e entrega a implementação a terceiros, ou se está progressivamente a assumir ambas as fases. O anúncio não resolve esta questão, mas nomear estas empresas como colaboradoras ao mesmo tempo que lança uma capacidade concorrente é a tensão que vale a pena acompanhar.

O plugin de design de produto trabalha a partir de UI em direto, não apenas de especificações

O plugin de design de produto foi concebido para transformar ideias iniciais em prototipos que as equipas possam avaliar. Duas capacidades destacam-se para o trabalho de frontend: a prototipagem a partir de um URL em direto e a conversão de capturas de ecrã estáticas em elementos interativos. Ambas tratam o estado existente da interface como ponto de partida, em vez de começarem por um briefing escrito, e o trabalho transita depois para o Figma e o Canva.

Isto é importante porque permite ao Codex encontrar os designers onde os seus artefactos já estão — uma página existente ou uma captura de ecrã simples — em vez de exigir que tudo seja descrito primeiro em texto. É a mesma lógica de 'trabalhar com as ferramentas que a sua equipa já usa' que a OpenAI aplica nos seis novos plugins, que juntos reúnem 62 aplicações e 110 competências.

As anotações trazem edição direcionada e por manipulação direta aos artefactos de frontend

As anotações, anteriormente usadas pelos programadores para refinar código, Markdown e websites gerados, estendem-se agora a documentos, folhas de cálculo e apresentações. O mecanismo baseia-se em seleção: aponta-se para um elemento específico e diz-se ao Codex o que alterar. O próprio exemplo da fonte é revelador para as equipas de frontend — selecionar a barra de navegação de um site e pedir ao Codex para atualizar a fonte, ou marcar um gráfico e pedir uma etiqueta mais clara.

Isto aproxima-se mais da manipulação direta do que da criação de prompts. Em vez de descrever novamente uma página inteira para alterar um único componente, a edição é limitada a uma região selecionada, preservando-se tudo o resto. A OpenAI enquadra as anotações como mais úteis depois do primeiro rascunho, 'quando o trabalho exige critério, feedback e iteração' — que é exatamente onde o trabalho de frontend costuma residir.

O que construir frontends alojados dentro do Codex exige das equipas

A implicação concreta aqui é de governação, não de novidade. Os Sites são alojados e partilhados por URL num workspace, e os administradores têm de os ativar nas configurações Enterprise, controlando também as permissões das aplicações subjacentes para os plugins específicos de cada função. Quando o Codex passa a gerar páginas interativas que leem dados do Snowflake, do Salesforce ou de um modelo financeiro e as mantém atualizadas, essas páginas tornam-se superfícies vivas que expõem dados internos — e não meros rascunhos descartáveis.

Com utilizadores não-programadores já a representar cerca de 20% da base do Codex, e a crescer a um ritmo mais de 3 vezes superior ao dos programadores, quem cria estes frontends deixará, cada vez mais, de ser engenheiro. O trabalho imediato para as equipas aplicadas é decidir o que um site gerado pelo Codex, com atualização automática, pode mostrar, quem o pode partilhar e como são delimitadas as suas ligações a dados — antes que circule um URL que ninguém do lado da plataforma tenha revisto.