Código que faz sentido não basta: o que TypeScript revela sobre programar com IA

Durante décadas, desenvolvedores discutiram linguagens de programação como quem discute futebol.

Java↳Java42 conteúdosNovidades do Java 26 (para desenvolvedores)Dev (Back & Front) · mar 2026Visual Studio Code para Java: o guia completo (dicas, configuração e extensões)Dev (Back & Front) · out 2025Quarkus: Modernizando a linguagem Java para a era da nuvemDev (Back & Front) · nov 2020Ver tudo em Dev (Back & Front) → ou C#? Python ou Ruby? JavaScript ou TypeScript? Go ou Rust?

Os critérios também eram conhecidos: performance, produtividade, facilidade de aprendizado, ecossistema, legibilidade e, claro, preferência pessoal.

Nada disso deixou de importar. Só que agora há mais um ponto na discussão: a capacidade de uma linguagem ajudar pessoas e máquinas a entender o que o código deveria fazer.

Quando apenas humanos escreviam software, boa parte do contexto podia permanecer implícita. Uma regra de negócio ficava na cabeça de alguém, em uma conversa no Slack ou em algum documento esquecido.

Com a entrada dos modelos de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → no desenvolvimento, essa tolerância ao implícito ficou mais cara.

Modelos são muito bons em produzir código que parece correto. O problema é que parecer correto e estar correto são coisas bem diferentes.

Press enter or click to view image in full size

O dado que mudou a conversa

Em agosto de 2025, TypeScript ultrapassou Python e JavaScript e se tornou, pela primeira vez, a linguagem com o maior número de contribuidores mensais no GitHub.

De acordo com o Octoverse 2025, a linguagem cresceu mais de 66% em número de contribuidores na comparação anual e ganhou mais de um milhão de desenvolvedores no período.

Não existe uma única explicação para isso.

Frameworks modernos passaram a adotar TypeScript como padrão. As ferramentas melhoraram, o custo inicial da tipagem caiu e o ecossistema JavaScript continua enorme.

Ao mesmo tempo, há outro fator ganhando peso: o desenvolvimento assistido por IA.

O próprio GitHub chama a atenção para a relação entre linguagens tipadas e esse novo modo de produzir software. Não porque modelos de IA sejam incapazes de escrever JavaScript, Python ou outras linguagens dinâmicas. Eles escrevem.

A diferença aparece quando erram.

Em uma linguagem tipada, parte desses erros pode ser detectada antes mesmo do código rodar.

Tipos são mais do que documentação

Considere esta função em JavaScript:

function calculateTotal(order) {
return order.items.reduce(
(total, item) => total + item.price * item.quantity,
0
);
}

Para quem conhece o sistema, talvez esteja claro o que existe dentro de order. Para quem acabou de chegar, incluindo uma IA, não está.

A função deixa várias perguntas em aberto:

• items Sempre existe?
• price É realmente um número?
• quantity Pode ser zero?
• Preço e total usam qual moeda?
• Existem descontos?
• Um item indisponível ainda pode aparecer no pedido?

Sem outras informações, a IA precisa inferir as respostas. E inferência, nesse caso, é apenas um nome mais elegante para adivinhação.

Em TypeScript, poderíamos tornar parte dessas premissas explícita:

type OrderItem = {
productId: string;
price: number;
quantity: number;
};

type Order = {
id: string;
items: OrderItem[];
};

function calculateTotal(order: Order): number {
return order.items.reduce(
(total, item) => total + item.price * item.quantity,
0
);
}

O exemplo ainda não descreve todo o domínio. Não informa moeda, descontos ou disponibilidade, por exemplo. Mesmo assim, já elimina várias interpretações possíveis.

Tipos e interfaces funcionam como contratos dentro do código. Eles ajudam o desenvolvedor que entrará no projeto daqui a seis meses, mas também ajudam a IA que recebeu acesso ao repositório há poucos segundos.

Contratos reduzem o custo de coordenação

Quanto maior o sistema, menor a chance de alguém conhecer todo o contexto.

Uma pessoa altera uma API criada por outra. Alguém consome esse retorno na interface. Outra pessoa implementa uma integração e, meses depois, um quarto desenvolvedor tenta entender por que tudo foi feito daquele jeito.

Contratos explícitos reduzem o volume de conhecimento que precisa ser reconstruído a cada mudança. Por isso, tipos costumam ganhar valor à medida que o sistema e o time crescem.

Agora há mais um participante nessa cadeia: a IA.

Ela não estava na reunião em que a regra de negócio foi decidida. Não se lembra da conversa no Slack e não conhece o incidente de produção ocorrido três meses atrás.

O modelo trabalha com o contexto que o projeto consegue fornecer. Quanto mais intenção estiver registrada no próprio código, menos espaço sobra para interpretações erradas.

Para a IA, o contrato também é um mecanismo de contenção

Um estudo publicado em 2025 sobre geração de código com modelos de linguagem encontrou um resultado interessante: em média, 94% dos erros de compilação observados no código gerado pelos modelos estavam relacionados a tipos.

É importante não extrapolar esse número. O estudo não prova que TypeScript elimina 94% dos erros produzidos por IA.

O resultado mostra algo mais específico: modelos conseguem gerar sintaxe plausível com facilidade, mas ainda produzem muitas inconsistências de tipagem. E esse é justamente o tipo de problema que uma ferramenta automática pode detectar.

Na prática, um agente de programação pode trabalhar assim:

1. Lê a tarefa;
2. Inspeciona o repositório;
3. Implementa a alteração;
4. Executa o verificador de tipos;
5. Analisa os erros;
6. Corrige a implementação;
7. Verifica os tipos novamente;
8. Executa os testes;
9. Apresenta o diff para revisão.

Nesse fluxo, o compilador também passa a orientar a IA. Ele oferece um retorno objetivo, imediato e barato sobre parte dos erros cometidos durante a implementação.

O compilador passou a fazer parte do contexto

Ainda pensamos em prompt como o texto digitado em uma caixa de conversa. Para agentes de programação, essa definição já não basta.

O contexto de um agente inclui:

• Tipos e interfaces;
• Schemas;
• Testes;
• Regras de lint;
• Documentação;
• Convenções do projeto;
• Mensagens do compilador;
• Estrutura do repositório;
• Resultados de comandos;
• Feedback do CI.

Cada um desses elementos influencia a próxima ação do agente.

Um sistema de tipos funciona como uma especificação parcial que acompanha o código. Ao contrário de um comentário desatualizado, porém, um contrato violado pode interromper o build.

Essa diferença é importante. Comentários dependem de alguém perceber que estão errados. O compilador reclama sozinho.

Isso já era útil quando todo o código era escrito manualmente. Com agentes capazes de executar comandos, interpretar erros e tentar outra vez, tornou-se ainda mais relevante.

Press enter or click to view image in full size

TypeScript não transforma código ruim em código bom

Tipagem não é certificado de qualidade.

Este código compila:

function applyDiscount(total: number, percentage: number): number {
  return total + total * (percentage / 100);
}

Os tipos estão corretos, mas a regra de negócio está errada: a função soma o desconto em vez de subtraí-lo.

Tipos conseguem impedir muitos estados inválidos, mas não conhecem automaticamente a intenção do negócio.

Também é possível neutralizar o sistema de tipos:

const response: any = await fetchData();

Ou contorná-lo com uma asserção:

const user = payload as User;

Ao usar any, Casts indiscriminados ou contratos vagos, o desenvolvedor basicamente pede ao compilador que confie nele.

Na era do código gerado por IA, convém reduzir os pontos em que o sistema precisa confiar cegamente, não importa se a promessa veio de uma pessoa ou de um modelo.

Há outra limitação importante: os tipos do TypeScript desaparecem em tempo de execução. Eles não validam, por conta própria, o conteúdo recebido de uma API, de um formulário, do banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → ou de um modelo de IA.

Dados externos precisam ser verificados na entrada do sistema. Tipagem estática e validação em runtime resolvem problemas diferentes e funcionam melhor quando usadas juntas.

Press enter or click to view image in full size

A discussão não se resume a TypeScript contra Python

Transformar esse assunto em outra disputa entre linguagens seria perder o ponto principal.

Python possui type hints. Java, C#, Kotlin, Swift, Go e Rust oferecem diferentes formas de expressar tipos e contratos. APIs podem ser descritas com OpenAPI. Dados podem seguir JSON Schema. Bancos de dados têm schemas. Testes também registram expectativas sobre o comportamento do sistema.

A tendência é maior do que TypeScript: à medida que mais software for produzido com auxílio de IA, aumentará o valor das tecnologias capazes de converter intenção implícita em restrições verificáveis.

TypeScript é um bom exemplo porque reúne três características:

• Um ecossistema enorme;
• Adoção massiva no desenvolvimento web;
• Um sistema de tipos expressivo que permanece compatível com o universo JavaScript.

Essa combinação tornou a linguagem especialmente adequada para projetos nos quais humanos e agentes trabalham sobre o mesmo código.

O que observar em um projeto TypeScript que usa IA

Se um time dissesse que está aumentando o uso de agentes para programar em TypeScript, a primeira pergunta não deveria ser qual modelo ele escolheu.

Antes disso, valeria examinar o projeto:

• O modo strict está habilitado?
• O CI executa o verificador de tipos?
• any é uma exceção ou aparece em toda parte?
• As entradas externas são validadas?
• Os tipos representam o domínio ou apenas fazem o compilador parar de reclamar?
• Os agentes podem executar testes e verificar os tipos antes de concluir uma tarefa?
• Existem regras contra @ts-ignore casts desnecessários e outras formas de silenciar erros?

Essas questões rendem menos discussão do que uma comparação entre modelos, mas têm impacto direto sobre o que chega à produção.

Gerar mais código só ajuda quando também existem mecanismos baratos para rejeitar o código ruim. A produtividade não depende apenas da velocidade de implementação. Depende também de descobrir o erro cedo, quando corrigi-lo ainda custa pouco.

Um novo critério para escolher tecnologia

Durante muito tempo, a pergunta foi: “Com qual linguagem o meu time consegue desenvolver mais rápido?”

Agora vale acrescentar outra: “Com quais linguagens, ferramentas e contratos conseguimos verificar mais rápido o que humanos e IAs produzem?”

Quando escrever código fica barato, entender se ele respeita a intenção original se torna uma parte maior do trabalho.

É isso que torna TypeScript tão interessante neste momento. A linguagem surgiu para deixar JavaScript mais previsível em projetos grandes. Anos depois, chegou à era da IA com uma característica particularmente útil: parte do conhecimento que antes existia apenas na cabeça dos desenvolvedores pode ser registrada em contratos que as máquinas também conseguem ler e verificar.

A próxima disputa entre linguagens talvez não seja decidida pela menor quantidade de código ou pela sintaxe mais elegante. O diferencial pode estar na capacidade de detectar, antes da produção, quando a interpretação da máquina não corresponde ao que o sistema deveria fazer.