Por uns quatro meses e meio, meu site vestiu a pele do TRANSMISSION: escuro, ciano, âmbar e propositalmente técnico.
Fundo azul-marinho puxado para o carvão. Acentos em ciano. Painéis envidraçados. Construí assim de propósito. Tinha passado dezoito anos em publicidade. Tinha me ensinado a programar aos quarenta. Queria que o site tornasse essa transição visível — que qualquer pessoa caindo num post do blog, passando o olho pelo wordmark e notando a estética de ferramenta de desenvolvedor pegasse o recado: essa pessoa cruzou para o outro lado.
Fez o serviço. Depois acabou.
No feriado prolongado do Memorial Day publiquei um redesign que não se parece em nada com o que veio antes. Light mode. Fundo de papel quente. Vermelho carmim no lugar do ciano. Filetes finíssimos no lugar de cards arredondados. Um visível "Vol. 04 · Issue NN" no canto — o volume conta os anos desde que comecei a construir em público, o issue é a semana ISO atual, e os dois estão programados para se atualizar sozinhos. A linha do dia em que você está lendo isto pode dizer Issue 22, ou 23, ou 41, dependendo de quando você chegar. Não tem ícone de Sparkles em lugar nenhum. O site já está no ar em chandlernguyen.com.
Eu poderia escrever um post inteiro sobre essas decisões. Mas a história mais útil é o fluxo de trabalho. Dividi o redesign entre dois modelos de IA diferentes. Claude Opus 4.7 com extended thinking cuidou do design. Codex sobre GPT-5.5 no nível mais alto de reasoning cuidou da execução. E a função /goal no Codex deixou ele rodar em autonomia por quase quatro horas seguidas, enquanto eu saía para caminhar ou jantava.
Quatro dias. Dois modelos. Quase trinta commits. Um site.
Aqui vai o que aprendi sobre qual modelo usar para o quê — e onde a fronteira ainda está.
Por que o TRANSMISSION precisava sair
Cruzei da publicidade para o código ao longo dos últimos dois anos. No começo deste ano o site tinha acompanhado o movimento: redesenhei como TRANSMISSION justamente para tornar essa transição visível. Quatro meses e meio depois, o recado já foi dado.
O próximo trabalho é outro. Quem chega de um post do blog, de uma thread no LinkedIn, de uma busca no Google não vem confirmar que eu escrevo código. Vem para aprender alguma coisa sobre IA em operações de mídia, para considerar comprar o curso, ou para comparar o curso, Prova, DIALØGUE e STRAŦUM como uma escada de produtos. O site precisava sinalizar menos e guiar mais.
A maneira mais fácil de descrever a virada: o site antigo era uma personalidade. O site novo é um modelo operacional. A mesma pessoa por trás, outro trabalho a fazer. Isso significava outra estética — mais leve, mais calma, editorial, o tipo de superfície onde um post longo consegue respirar e um CTA do curso consegue soar honesto em vez de empurrado. Papel quente no lugar do vidro.
Mas o problema mais difícil não era a estética. Era o volume. O site tem treze idiomas, umas oito superfícies públicas (home, blog, post, products, learn, about, ask, página de venda do curso), um fluxo autenticado de acesso ao curso, um checkout do Stripe e um endpoint do RAG da Sydney. Reconstruir tudo isso na mão teria levado semanas. Eu não tinha semanas.
Então dividi o trabalho entre dois modelos de IA.
Por que separar design e execução
Design e execução são tarefas cognitivas diferentes.
Design é lento. É julgamento sobre composição, sobre contenção, sobre se um tom de papel quente fica amarelo demais num iPhone e outro tom fica frio demais. É perguntar "que tipo de superfície isto está tentando ser?" antes de "como a gente renderiza esta seção?". Bom trabalho de design comprime tempo — você pensa por duas horas e aí toma uma decisão que economiza dez horas de execução.
Execução é rápida. É aplicação de padrão. Dado um design system, gere os componentes. Dado um componente, conecte ele em treze idiomas. Dado o layout de uma página, publique as variantes. O trabalho não é menos qualificado, mas é menos ambíguo. A resposta certa quase sempre é defensável contra a spec.
Modelos de IA diferentes são melhores em tarefas cognitivas diferentes. Pela minha própria experiência nos últimos meses — primeiro com o Claude Opus 4.6 e agora com o 4.7, os dois em modo extended thinking — o Opus é o parceiro mais completo. Melhor em brainstorming. Melhor em julgamento de design. Mais lento e menos cirurgicamente preciso em código puro, mas considera a composição inteira antes de responder e raciocina de um jeito que captura por que uma fonte parece amigável demais e outra parece a certa.
O Codex sobre GPT-5.5 no nível alto de reasoning soa como um engenheiro de software sênior competente que nunca chegou perto do time de design. É rápido. É excelente em uso de ferramentas em vários passos — abrir arquivos, ler, editar, rodar testes, abrir o próximo. Não tem opiniões fortes sobre se um botão está alto demais, mas entrega o botão, e entrega cada variante do botão em treze idiomas sem reclamar. A função /goal dele te deixa entregar um alvo — por exemplo, "convert the v3 design tokens into the Next.js app, wire the new shell, ship working BottomNav, MobileAppBar, ReadingProgress, verify the build passes with the flag off" — e ir embora. Ele planeja os sub-passos, executa, roda o build, conserta o que quebra e segue. O trecho mais longo que rodou sem supervisão pra mim, neste projeto, foi pouco menos de quatro horas.
Tenho que admitir que não planejei essa divisão de forma deliberada no começo. Eu tinha tido a conversa de design com o Opus nos dias anteriores ao fim de semana. Quando o feriado começou, eu já estava com o documento de direção de design e o protótipo de desktop na mão. O fim de semana em si foi quando passei a execução para o Codex, e na primeira hora já percebi o quanto cada modelo encaixava melhor na sua metade do trabalho.
O que o Opus fez: a fase de design
O trabalho de design aconteceu numa longa conversa com o Opus nos dias anteriores ao redesign. Dessa conversa saíram dois artefatos, ambos hoje moram no repositório:
1. Um documento de direção de design. Seis arquivos markdown em doc/v3-design/ — o porquê, os tokens, os padrões mobile, as especificações de página, as restrições de acessibilidade, o plano de execução. Mais de treze mil palavras de decisão, em grande parte escritas pelo Opus a partir de um brief que eu tinha dado. A diretriz: "o próximo site precisa parecer uma pequena revista impressa, não um dashboard SaaS. Conquistar a atenção pela contenção. Usar o framework Operating Model 2×2 como assinatura visual."
2. Um protótipo HTML para desktop. Um diretório plano em public/design-prototype-v2/ com seis páginas e um style.css compartilhado. Sem React, sem Tailwind, sem framework — só HTML escrito na mão pra eu poder clicar por cada página num servidor local e sentir se o design system de fato se sustentava como sistema. O protótipo virou a fonte da verdade do tratamento visual no resto do fim de semana. Na dúvida, durante a reconstrução, a resposta era "que combine com o protótipo."
O Opus tomou as decisões que mais importavam. Alguns momentos específicos:
-
A inversão da fonte. Uma rodada de design anterior tinha travado o Manrope como fonte display por disponibilidade e facilidade de publicar — definida numa sessão com o Claude Sonnet 4.6. Dezoito horas depois eu já tinha levado a conversa de design para o Opus 4.7 com extended thinking, e o primeiro movimento do Opus foi reconsiderar essa trava. Depois que passei uma noite na página oficial de specimen do PP Neue Montreal comparando letras, a troca entrou. A mensagem do commit parece cena de crime tipográfica: "Manrope rendered too rounded and friendly... Satoshi has the same condensed-grotesque proportions, the same double-storey
a, single-storeyg, sweptRleg, cleanly-sheared terminals." O detalhe interessante é que dois modelos diferentes do Claude chegaram a julgamentos diferentes sobre a mesma decisão. O Sonnet escolheu a opção segura. O Opus escolheu a certa. -
A escolha do carmim. Ciano é o acento padrão da IA. O Opus e eu chegamos no vermelho carmim —
#c33824, um vermelho de tinta de gráfica, a cor da marca de um editor numa prova de página ou de um volume latino numa estante da Loeb Classical Library. O raciocínio foi específico: "o site está tentando soar editorial, não ferramenta de desenvolvedor. Ciano sinaliza tech. Carmim sinaliza ofício. Use o carmim com parcimônia, sempre em alto contraste, idealmente sobre papel quente." Essa não é uma decisão que um modelo otimizado para execução fosse buscar sozinho. -
O Operating Model como assinatura visual. O framework 2×2 que eu ensino no curso — Automate / Protect / Deepen / Change — vira uma marca discreta do site novo. Na implementação atual ele aparece em dois lugares contidos: o bloco de tese da home e um pequeno marcador de tese nos posts longos. O framework em si era meu; a decisão de transformá-lo na identidade visual do site saiu da conversa de design com o Opus.
-
Claro acima do escuro. O Opus argumentou pelo light mode como personalidade e dark mode como variante suportada. O argumento: leitura longa é mais fácil em papel quente do que em vidro; etiquetas de preço soam mais honestas em fundos claros; quase toda ferramenta de IA já nasce dark por padrão, então claro é o diferencial. Discordei por umas horas, depois concordei.
O Opus foi sobretudo o loop de design e revisão; o Codex fez as passagens de implementação. O trabalho do Opus era a parte em que ser lento valia a pena.
O que o Codex fez: a fase de execução
Uma vez prontos o documento de design e o protótipo, o trabalho migrou para o Codex.
Abri uma sessão nova do Codex, passei os arquivos de direção de design como contexto e comecei a rodar sessões de /goal. Cada goal era um alvo de vários passos com um estado final claro:
Goal: Convert the v3 design tokens from
doc/v3-design/components/tokens.cssintosrc/app/globals.css. Remove the conflicting TRANSMISSION tokens. Wire up the three new fonts viasrc/lib/fonts.tsandsrc/app/layout.tsx. Generate the v3 shell behind the feature flagNEXT_PUBLIC_ENABLE_V3_DESIGN. Ship a workingBottomNav,MobileAppBar, andReadingProgress. Verify the build passes and that no existing pages are visually affected when the flag is off.
Esse tipo de alvo em várias etapas é exatamente para o que o /goal foi pensado. O Codex planeja os sub-passos, executa, roda pnpm build pra checar erros de tipo, conserta o que quebrou, roda o build de novo e segue. Voltei de uma caminhada e o shell de v3 estava no ar dentro do código atrás da flag, com as novas fontes carregadas e o bottom nav renderizando no mobile.
Sessões de /goal seguintes:
- Gerar as páginas home e archive de v3 a partir do protótipo.
- Gerar o layout de post de v3, incluindo a barra de progresso de leitura e o botão de compartilhar de v3.
- Gerar as páginas products e learn de v3, seguindo a estrutura da escada de produtos definida na spec.
- Alinhar visualmente ao v3 as páginas existentes de venda do curso, login, signup, MFA e access, sem mexer em nada da lógica de Stripe ou de Supabase Auth por baixo.
- Localizar as superfícies de v3 do curso e do Ask Sydney nos treze idiomas, usando os arquivos
messages/{locale}.jsonexistentes como fonte de tradução.
A corrida mais longa concluída sem intervenção foi de pouco menos de quatro horas. A mais curta, em torno de quarenta e cinco minutos. Nos quatro dias publiquei quase trinta commits — a maioria primeira ou segunda passagem do Codex, com pequenos ajustes manuais quando a saída do modelo estava correta mas não no formato exato que eu queria. Sendo honesto: acho que o Codex escreveu a grande maioria do código que hoje roda em produção. O resto fui eu que escrevi ou editei.
A coisa mais útil do /goal não é a velocidade. É a autonomia. A maior parte das sessões de código que rodei com ferramentas de IA exige que eu fique no teclado — confirmar uma alteração, aceitar o próximo arquivo, revisar o diff. O /goal te deixa especificar o estado final que você quer e ir embora. Você volta ou para uma alteração concluída ou para uma sessão pausada no ponto exato em que o modelo precisa que você tome uma decisão. A forma do trabalho é outra. Você vira um planejador de sessões de várias horas em vez de babá de edições individuais.
Onde a fronteira ainda está
Dividir design e execução entre dois modelos não é uma mágica. Ainda existem momentos em que um modelo precisa do outro, e alguns momentos em que nenhum dos dois sozinho dá conta.
O ícone de Sparkles. O Codex gerou um shell mobile de v3 limpo com um ícone de Sparkles ✨ na aba do Ask — o sinal universal de ferramenta de IA. O ícone estava correto contra a spec; a spec não dizia "não use o clichê." Notei alguns dias depois e voltei ao Opus pra discutir substitutos. Passamos por várias iterações: a marca do Operating Model, depois um ponto de interrogação em itálico Newsreader em vermelho carmim — o tipo de glifo que você acharia como marginália num ensaio antigo. A solução final foi ideia do Opus. O Codex publicou em quinze minutos.
O momento Hinomaru. Enquanto a marca do Operating Model estava no canto superior esquerdo da app bar mobile, do lado do meu nome, eu vinha olhando pra ela havia dois ou três dias. Um pequeno ponto carmim sobre um quadrado de papel quente. Aí uma noite olhei pra ela do jeito que outra pessoa olharia e senti um pequeno solavanco de percepção. Parecia exatamente a bandeira do Japão. O Hinomaru. Um pequeno sol vermelho sobre um campo claro. Nem o Opus nem o Codex pegaram isso. O Opus tinha desenhado a marca; o Codex tinha implementado; os dois tinham revisado. A associação visual era um padrão cultural que nenhum dos dois modelos enxergava. Apaguei a marca do wordmark e parti pra outra solução. (O mesmo ? em itálico acabou ocupando o espaço dela na aba do Ask.)
O rollout dos 13 idiomas. O Opus poderia ter desenhado as nuances de UI de cada idioma com cuidado, mas teria levado dias. O Codex não conseguiria fazer o julgamento de design sozinho, mas conseguiu publicar os treze idiomas numa noite assim que os padrões estavam definidos. Esse é o exemplo mais literal da divisão: design lento, execução rápida.
Escolher três fontes que conversam entre si. O Opus escolheu Satoshi (display), Newsreader (acento itálico) e JetBrains Mono (labels). O Codex não teria escolhido essa combinação sozinho — e nem tenho certeza de que eu teria, sem a lentidão do Opus na conversa. A composição de três fontes é uma escolha de design, não de execução.
A conversa entre os dois sistemas acontece na minha cabeça, não entre os modelos. Essa é a parte que ainda não dá pra automatizar em 2026 — e acho que é a parte que define o que gosto significa agora.
Contas honestas
Quatro dias. Quase trinta commits. A v3 em produção está no ar em chandlernguyen.com. O site novo está fazendo o trabalho novo — ajudar quem chega a encontrar o que ler em seguida em vez de avisar que eu cruzei pro outro lado.
O site tem um problema pendente que ainda estou perseguindo. Na hora do rascunho, o Lighthouse mobile em produção mostrou o archive do blog em 4,6 segundos enquanto o meu trace local do Chrome DevTools mostrou a mesma imagem pintando em 264 milissegundos — mesmo código, modelos de rede muito diferentes. Minha hipótese principal hoje é pressão de preload de fontes: três webfonts pré-carregadas mais três chunks de CSS que bloqueiam o render disputando com a imagem na reta final numa conexão mobile com throttling. Publiquei a versão de menor alavanca dessa correção no último dia e ainda preciso de uma nova rodada de Lighthouse pra confirmar que pegou. O post que você está lendo foi escrito antes de eu ter o número pós-fix.
Custo das assinaturas: minha assinatura do Codex no nível mais alto, mais a assinatura do Claude Max que eu já tinha. Juntas, algumas centenas de dólares por mês. Barato, pelo tanto que entrega.
O fato de v3 ter acontecido em quatro dias em vez de três semanas se explica em grande parte porque as fases de design e execução foram separadas e atribuídas aos modelos que eram melhores em cada uma. Não acho que isso seja universal. Existem projetos em que um modelo só dá conta dos dois lados, e projetos em que nenhum dos dois é o parceiro certo. Mas para um redesign de várias páginas, vários idiomas e várias superfícies, com um ponto de vista de design forte, essa divisão é o fluxo de trabalho ao qual eu voltaria de novo.
Se você fez recentemente uma reconstrução sua assistida por IA, eu adoraria de verdade ouvir como você dividiu o trabalho. Usou um modelo só, de ponta a ponta? Dividiu por fase, como eu fiz, ou por algum outro eixo — por componente, por arquivo, por tipo de tarefa? Acho que a próxima onda do ofício de build-in-public vai ser sobre qual IA para qual parte do trabalho, não só sobre se você usa IA ou não.
Se você quiser ver o resultado, está lendo ele. A home está em chandlernguyen.com. A escada de produtos está em /pt/products/. O curso que deu origem à ideia inteira de "operating model" está em /pt/learn/.
Abraços, Chandler