Thesis 2: coding visual com gerador, avaliador e checkpoint
A nova disciplina do Thesis 2 separa criação, crítica e verificação para evitar que uma interface apenas “pareça pronta”.
O problema do one-shot
Interfaces ambiciosas degradam quando um único passe tenta decidir arquitetura, estética, interação e QA ao mesmo tempo. O Thesis 2 passa a tratar essas responsabilidades como papéis distintos, mesmo quando executadas pelo mesmo runtime.
Gerador primeiro, avaliador depois
O gerador recebe o briefing, o estado real do código e as referências visuais. O avaliador recebe a saída e um rubric explícito: coerência do conjunto, originalidade, acabamento e funcionalidade. A crítica não pode ser “ficou bonito”; precisa localizar diferenças observáveis.
Mundo visual, não decoração
Para páginas cinematográficas, o prompt agora exige um modelo de mundo: fonte de luz, atmosfera, planos de profundidade, textura, silhueta principal, oclusão de primeiro plano e crop responsivo. Gradiente, blur e partículas entram apenas quando explicam esse mundo.
Screenshot como evidência
Quando há navegador ou referência de imagem, o loop termina apenas depois de comparar screenshot, hierarquia, ocupação de espaço, ritmo tipográfico e estados. O melhor checkpoint é preservado para que uma iteração posterior não piore o que já estava resolvido.
Código real continua sendo o limite
Nenhuma ambição visual autoriza quebrar contrato de rota, estado, acessibilidade ou performance. O avaliador visual trabalha junto da validação de sintaxe, runtime, responsividade e interação.
Por dentro de Poder de veto do avaliador
O salto de qualidade acontece quando o avaliador pode rejeitar uma tela tecnicamente válida por composição ruim, hierarquia fraca, excesso de elementos ou interação incompleta. Thesis 2 preserva o melhor checkpoint aprovado e só promove uma nova versão quando ela melhora o conjunto, não apenas uma métrica isolada.
- latência e custo compatíveis com a complexidade
- identidade pública do modelo preservada em fallback
- esforço extra só quando compra evidência
Falha específica: Poder de veto do avaliador
O risco é deixar generator e evaluator compartilharem o mesmo viés. Se ambos premiam volume de código, a revisão vira cerimônia e uma regressão visual pode parecer progresso.
Evidência que fecha Poder de veto do avaliador
A prova forte combina execução, screenshot comparável, estados de interação e um checklist de critérios objetivos: foco, leitura, densidade, crop, contraste, responsividade e ausência de controles mortos.
