Código é Modelo Conceitual: Joshi (Thoughtworks) Ratifica o Harness

Unmesh Joshi, consultor principal na Thoughtworks, publicou What Is Code? no site de Martin Fowler em 12 de maio de 2026. A assinatura importa porque o texto está hospedado em martinfowler.com mas é escrito por Joshi, e o argumento carrega o peso de entrega da Thoughtworks, não a coluna pessoal do Fowler. A tese vem limpa: “Código continua sendo instrução para uma máquina. Mas também é um modelo de entendimento. Na era dos LLMs, esse segundo papel se torna ainda mais importante.”

Nós dizemos a mesma coisa há um ano, com outra palavra. Joshi chama de modelo conceitual. Nós chamamos de harness. O texto é a versão canônica, carimbada pela Thoughtworks, de um argumento que vimos sustentando em ensaios, e merece leitura cuidadosa pelo lugar em que ele deixa a pergunta de verificação.

Os Dois Papéis do Código

Joshi abre com o desdobramento que organiza o resto do texto. Código sempre teve dois papéis simultâneos. O primeiro é mecânico: instrução para uma máquina. Arquivos-fonte são compilados ou interpretados, a CPU executa, a rede responde. O segundo é conceitual: um modelo do domínio do problema expresso em notação precisa o suficiente para ser checada por um compilador e lida por um humano.

Pela maior parte da história do software, esses dois papéis vinham soldados. Você não podia separá-los porque não podia se dar ao luxo. Escrever o modelo conceitual era o mesmo ato que escrever as instruções, e o custo do segundo papel era pago fazendo o primeiro com cuidado.

LLMs quebram essa solda. O primeiro papel, escrever instruções, é onde os modelos são bons. Produzem código que roda a partir de um prompt suficientemente especificado em segundos. O segundo papel, construir o modelo conceitual, é algo que eles aceleram, mas não substituem. O modelo ainda precisa estar correto, coerente e alinhado com o jeito que o negócio funciona de fato. Alguém precisa verificar isso.

O enquadramento de Joshi é que o primeiro papel está sendo comoditizado e o segundo papel está se tornando mais valioso. O centro de gravidade da engenharia de software se desloca de digitar para modelar.

TLA+, DSLs e Conceitos de Domínio

Os exemplos que Joshi percorre são específicos, e eles importam. Ele mostra pseudo-código em TLA+ expressando isolamento de snapshot com mais clareza do que o Java verboso equivalente. O Java compila. O TLA+ não compila, no sentido de produção. Mas o TLA+ é o modelo conceitual. É o que você lê quando quer entender se o algoritmo está correto. O Java é o que roda.

Ele segue para construção de DSL. Uma DSL bem desenhada dá uma interface parecida com inglês em cima de uma camada estável de abstração. A DSL é o modelo conceitual exposto ao usuário. A camada de abstração por baixo é a instrução para a máquina. Quando times constroem uma DSL boa, estão separando explicitamente os dois papéis, e a separação é o que torna o sistema usável.

Depois ele chega na modelagem de domínio. O exemplo de varejo mapeia conceitos de catálogo em construtos web: GET, POST, PUT, DELETE em recursos de Catálogo. O mapeamento é o modelo conceitual. Os handlers HTTP são as instruções. Um time que erra o mapeamento pode escrever handlers HTTP perfeitamente funcionais que resolvem o problema errado.

Cada exemplo é um jeito de apontar para a mesma observação. O artefato valioso é o modelo, não as instruções. As instruções são derivadas.

Testes e Tipos Como Guardrails

É aqui que o texto de Joshi faz o trabalho que ratifica nossa posição. Ele reenquadra testes e tipos. Eles não são, nessa moldura, sobre correção no sentido clássico em primeiro lugar. São sobre acurácia do modelo. Um sistema de tipos codifica um modelo de estados válidos. Um teste codifica um modelo de comportamento esperado. Juntos, são os artefatos que dizem “o modelo conceitual é para ser assim”.

Na era LLM, esse papel vira de conveniência para carga estrutural. Quando um modelo gera código, a pergunta não é se o código compila. Modelos produzem código que compila por padrão. A pergunta é se o código gerado corresponde ao modelo conceitual que o time tem na cabeça. Testes e tipos são o único jeito sustentável de responder essa pergunta em velocidade.

Joshi escreve sobre isso como guardrails para acurácia do modelo. Nós escrevemos sobre isso como infraestrutura de verificação. A substância é a mesma. Quando a IA comoditiza o primeiro papel do código, o segundo papel exige um substrato que consiga verificá-lo, e esse substrato é exatamente a disciplina que a maioria dos times já tem pela metade e que vinham tratando como custo administrativo.

O Cruzamento Com o Harness

Vale ser preciso sobre o mapeamento porque os vocabulários convergem, mas não colidem.

O “modelo conceitual” de Joshi é o que vive no nosso harness como a forma codificada do trabalho: os tipos, os casos de teste, o schema, o glossário do domínio, as restrições arquiteturais. O “vocabulário” dele mapeia no que chamamos de vocabulário cruzado entre disciplinas, que viaja com o trabalho entre marketing, design, jurídico e engenharia.

“Testes e tipos como guardrails”, em Joshi, é exatamente o que chamamos de camada de verificação. O enquadramento dele enfatiza a acurácia do modelo; o nosso enfatiza a reprodutibilidade da saída assistida por IA. São a mesma propriedade vista de dois ângulos. Um modelo que não pode ser verificado vai derivar; uma saída que não pode ser verificada não pode ser reproduzida.

Onde nosso enquadramento adiciona algo que o texto de Joshi não força: tratamos o modelo conceitual como artefato sob governança ativa, com posse, versionamento e controle de mudança. Joshi trata como atributo de qualidade do código. A cultura de entrega da Thoughtworks já tem esses hábitos de governança embutidos, então o texto pode tomá-los como dados. Para times sem essa linha de base, a pergunta operacional é como o modelo conceitual se mantém quando ninguém é dono dele.

Por Que a Assinatura Importa

Uma nota sobre atribuição. O texto está publicado em martinfowler.com e vai circular com o nome do Fowler colado. Isso é atribuição errada. Joshi é da Thoughtworks. Fowler é o Chief Scientist da Thoughtworks. O site é do Fowler, a linhagem é Thoughtworks, e o autor é Joshi.

Isso importa porque o argumento tem respaldo institucional. Quando um consultor principal da Thoughtworks publica no site do Chief Scientist da firma que “código é modelo conceitual de entendimento, e testes e tipos são guardrails desse modelo na era LLM”, não é hipótese de um único escritor. É consenso da prática de uma firma que vem entregando trabalho de IA aumentada em escala há dois anos. Citar como Joshi mantém o peso institucional intacto. Citar como Fowler reduz a um ensaio pessoal, o que não é.

O Que Fazer Agora

Três ações para times lendo isso.

Audite a superfície do modelo conceitual no seu código. Os tipos, os schemas, o glossário do domínio, os contratos de teste. Liste-os. Se eles não são artefatos explícitos com dono, a era LLM já elevou seu custo de verificação e ninguém está pagando.

Reenquadre o investimento em teste e tipo internamente. A narrativa dentro dos times de engenharia tem sido “testes atrapalham, IA acelera”. O texto de Joshi inverte a polaridade. Testes e tipos são o que faz a velocidade de IA virar saída reprodutível. O reenquadramento é retórico, mas muda conversas de orçamento.

Leia Joshi direto, não os resumos de segunda mão. O texto é curto e os exemplos sustentam o argumento. Os resumos vão perder o exemplo de TLA+, que é o que carrega o caso para qualquer líder de engenharia.

O vocabulário vai continuar se multiplicando. Modelo conceitual, harness, prompt estruturado, acurácia de modelo, substrato de verificação. A coisa para a qual todos apontam é a mesma. O segundo papel do código é agora a superfície onde valor de IA se acumula ou evapora, e os times que construírem artefatos para essa superfície serão os times cujos investimentos em IA vão compor.

Fontes

Unmesh Joshi (Thoughtworks). “What Is Code?.” Publicado em martinfowler.com, Maio de 2026.

A Victorino ajuda times a construir os modelos conceituais, vocabulários e camadas de verificação que tornam a colaboração humano-IA segura em escala: contato@victorino.com.br | www.victorino.com.br