🖥️ O Browser Embutido do Codex App
Esse recurso não existe no Claude Code nem no Cursor. É um browser nativo dentro da janela do Codex App, lado a lado com o código. O agente vê o que você vê — clique, scroll, formulário, console.
🪟 Layout side-by-side
Hot reload acoplado
Mudou código → browser recarrega instantâneo. Sem alt-tab.
Console capturado
Erros JS aparecem no chat do agente automaticamente.
DOM inspecionável
Agente vê HTML renderizado, não só o código fonte.
📌 Por que isso muda o jogo
Em Cursor/Claude Code você descreve o bug em texto e reza. No Codex App o agente vê o problema com seus olhos. A diferença em qualidade de fix é gigante — especialmente em CSS e layout, onde palavras falham.
👆 Anotação Visual
Descrever um bug visual em texto leva 5 frases. Apontar e dizer "esse botão tá grande demais" leva 2 segundos. É o "select to fix" do design — point-and-click pra IA.
🔄 Workflow de anotação
❌ Sem anotação visual
"Tem um botão na lista de conversas, eu acho que é o de arquivar, ele tá com padding-x grande demais e o texto não cabe quando o nome é longo"
Agente: 3 perguntas de volta, 2 minutos, fix possivelmente errado.
✅ Com anotação visual
[clica no botão] "padding-x menor"
Agente: vai direto no ConversationItem.tsx:42, ajusta, pronto em 8s.
🎯 A regra do "menos palavras, mais cliques"
No fluxo visual, sua descrição tende a ficar curta — "menor", "mais espaço aqui", "alinhar à direita". Isso é certo. A imagem fornece o contexto que o texto teria que reconstruir.
⚡ Iteração Rápida: fix → reload → verifica
Compressão de tempo de feedback é multiplicador direto de qualidade. 12 iterações em 1 hora batem 3 iterações em 1 hora — sempre. O loop apertado é o que torna polish viável.
⏱️ Comparação de tempo de feedback
🔁 O loop apertado em prática
- 1. Comece pela tela mais visível — landing/inbox/dashboard.
- 2. Faça 1 anotação por vez (não acumula 5 antes do agente rodar).
- 3. Hot-reload aplica → você vê → próximo problema.
- 4. Não pare pra "também vou ajustar isso" — anota e segue.
- 5. Quando atingir "tá ok", commita ANTES de seguir polindo.
🎯 Polish é exponencial, não linear
O 10º ajuste é o que faz a tela parecer profissional, não o 3º. Iteração rápida torna o 10º ajuste barato — sem ela, você desiste no 4º porque dá preguiça. É literalmente o que separa "MVP de aluno" de "produto que paga R$ 25k".
📱 Responsivo: Toggling Viewport
Responsivo testado depois é responsivo quebrado. Testar viewport durante a construção pega 80% dos bugs antes deles existirem.
📐 Os 3 viewports que importam
| Viewport | Largura | Tailwind | Comportamento esperado |
|---|---|---|---|
| 📱 Mobile | 375px | <sm | Lista full-width, thread em modal |
| 📋 Tablet | 768px | md | 2 colunas (lista + thread), painel some |
| 🖥️ Desktop | 1280px+ | lg | 3 colunas completas |
⚙️ Tailwind responsivo no inbox
<div className="grid grid-cols-1 md:grid-cols-[280px_1fr] lg:grid-cols-[280px_1fr_280px] h-screen">
<ConversationList className="border-r border-neutral-800" />
<MessageThread className="hidden md:flex" />
<ContactPanel className="hidden lg:block border-l border-neutral-800" />
</div>📌 Touch targets: 44px é mínimo
Apple HIG e Material Design concordam: botões em mobile precisam de pelo menos 44×44 pixels. Botão lindo de 24px no desktop vira frustração no celular. Teste no viewport mobile e clique em tudo com o dedo (sim, com o dedo, não com o mouse).
📸 Capturando Bug com Screenshot Anotado
Bug descrito em texto vira ping-pong de 6 mensagens. Bug descrito em screenshot anotado é fechado na primeira resposta. Vale ouro com cliente, com colega, e com o você do dia seguinte.
🎯 Anatomia de um screenshot que resolve
📋 Template de bug report
## Bug: [resumo de 1 linha] **Onde:** /inbox (conversation thread) **Viewport:** 768px (tablet) **Branch:** feat/multi-channel ### Repro 1. Abrir uma conversa com 50+ mensagens 2. Scroll até o topo 3. Receber nova mensagem (mock) ### Esperado Manter scroll position se usuário não estiver no fim. ### Atual Scrolla pro fim mesmo se eu estiver lendo histórico. [screenshot-anotado-aqui.png]
💼 Pro cliente: vale a vida útil do contrato
Cliente que recebe bug report bem feito confia mais e cancela menos. É um dos rituais que aparenta "só boa educação" mas é estratégia comercial direta. O Codex App captura screenshot + anotação direto no chat — use ABUNDANTEMENTE.
🛑 Quando Voltar pro Plan Mode
Iteração visual é poderosa pra polir; péssima pra arquitetar. Saber a hora de parar e replanejar evita acumular 15 fixes em código que precisava de reescrita.
🚨 Sinais de alerta — pare e plan mode
✅ Iteração visual é boa pra:
- • Polish de espaçamento, cor, tipografia
- • Microcopy e labels
- • Estados visuais (hover, focus, active)
- • Responsividade incremental
- • Animações sutis
❌ Iteração visual é ruim pra:
- • Mudança de arquitetura de componentes
- • Refatoração de estado global
- • Adição de feature nova grande
- • Performance / re-renders
- • Migração de biblioteca
🎯 A regra dos 3 fixes
Se você precisou pedir 3 fixes no mesmo componente nas últimas 10 minutos, pare. Abra o plan mode, descreva o que está acontecendo no nível arquitetural ("o componente X está fazendo demais; quero quebrar em Y e Z"), e deixe o agente propor um refactor antes de mais um band-aid. Custa 5 minutos pensar e economiza 2 horas refazendo.
✅ O que Aprendemos
Próxima Trilha:
Trilha 4 — Backend e Integrações: Convex no InboxAI real, integrações WhatsApp/Instagram/email/web chat, agentes IA qualificadores, autenticação e deploy.