Implantação do modo strict do TypeScript em apps gerados por IA

O que muda no modo strict (e por que apps gerados por IA quebram)

O modo strict do TypeScript não é uma única regra. É um conjunto de verificações que impede o compilador de aceitar suposições. Ativá-lo funciona melhor quando você o trata como colocar detectores de fumaça melhores, não como reconstruir a casa inteira.

Quando você define "strict": true no tsconfig, o TypeScript ativa várias configurações que muitas vezes estão desligadas em protótipos. As mais visíveis são:

• strictNullChecks: força você a tratar null e undefined intencionalmente
• noImplicitAny: impede tipos “qualquer coisa” silenciosos
• strictFunctionTypes: pega parâmetros de função inseguros
• noImplicitThis: evita o problema de “this é qualquer coisa”
• alwaysStrict: aplica as regras do modo estrito do JavaScript

Apps gerados por IA frequentemente quebram com essas verificações porque “funcionam” se apoiando em tipagem fraca e suposições ocultas: parsear respostas de API como any, assumir que um campo sempre existe, tratar entrada do usuário como o tipo certo ou passar objetos incompletos entre camadas. Tudo parece ok até que um usuário real bata num caso de borda. Aí aparecem erros de undefined, fluxos de autenticação quebrados ou dados com formatação diferente do esperado pela UI.

O modo strict reduz bugs em runtime porque torna esses problemas ruidosos durante o desenvolvimento. Normalmente ele detecta:

• acessar propriedades em valores possivelmente undefined
• confundir formatos de dados (por exemplo, { id: string } vs { id: number })
• chamar funções com argumentos faltando ou errados
• uso inseguro de any que esconde erros reais de tipagem

A primeira habilitação costuma parecer barulhenta. Isso é normal. Pense nisso como um refactor controlado: você está adicionando clareza e guardrails em áreas pequenas, não reescrevendo o app.

Inventário rápido: mapeie as partes bagunçadas antes de mexer na configuração

Antes de tocar nas configurações de strict, passe uma hora mapeando onde bugs em runtime têm mais chance de se esconder. Em projetos gerados por IA, uma mudança em um arquivo “core” pode fazer erros explodirem por todo o repositório.

Comece localizando onde os dados entram no app e são reutilizados. Tipos fracos se espalham mais rápido por:

• chamadas de API e helpers de cliente (wrappers de fetch, instâncias axios, parsing de resposta)
• autenticação e manipulação de sessão (armazenamento de token, objetos de usuário, middleware)
• camada de banco de dados e queries (modelos ORM, SQL cru, migrations)
• utilitários e constantes compartilhadas (helpers de data, acesso a env, feature flags)
• código de ligação entre páginas/componentes e serviços (mapear JSON para estado da UI)

Em seguida, escaneie padrões que o modo strict vai expor. Você ainda não está consertando, apenas identificando: muito any, parâmetros any implícitos, JSON sem tipo, campos opcionais usados como se existissem sempre e IDs “stringly typed” que se confundem (userId vs orgId).

Decida o escopo cedo para que o trabalho fique gerenciável. Você pode escalonar o que vai ser verificado por tipo: código da app primeiro, depois testes, scripts e tooling de build. Um ponto comum de partida é “apenas código da app”, assim você não fica travado por scripts de dev pontuais.

Por fim, mantenha um documento leve de notas da migração. Registre tipos recorrentes de erro (como “Object is possibly undefined”) e sua correção preferida (cláusula guard, valor padrão ou um tipo melhor). Quando você consertar o 30º erro parecido, vai agradecer por ter anotado.

Escolha uma estratégia de etapas que mantenha o trabalho manejável

Um rollout do modo strict dá certo quando você escolhe unidades de trabalho que conseguem ser concluídas. Apps gerados por IA costumam ter qualidade desigual: uma pasta está ok, a próxima está cheia de any implícitos, checagens de null faltando e tipos copiados. Escalonar mantém você avançando sem transformar a base inteira num muro vermelho.

Escolha uma unidade de migração que combine com a organização do projeto: por pasta (projetos em camadas), por feature (rotas + UI + serviços), por pacote (monorepos) ou por ponto de entrada (um worker, webhook ou job runner que causa a maioria dos crashes).

Continue lançando features enquanto migra. Evite uma branch longa de “modo strict” que fica divergindo por semanas. Trabalhe em PRs pequenos e faça merge com frequência. Se a strictness não está ativada em todo lugar ainda, trate a “área strict” como protegida: novos arquivos nela devem estar limpos, e mudanças fora não devem enfraquecer tipos.

Também escolha uma pessoa para decidir padrões de migração. Não é sobre hierarquia, é sobre consistência. Alguém precisa responder perguntas como: quando usar unknown vs any, como nomear tipos compartilhados e quando um type guard rápido é suficiente versus quando vale a pena refatorar.

Para cada pedaço, defina “pronto” claramente: as checagens strict passam para aquele pedaço, testes passam (ou você adiciona um teste pequeno para o caminho arriscado), escapes temporários estão rastreados e o código continua legível.

Plano passo a passo para rollout (passos pequenos, menos surpresas)

Comece garantindo que você consiga dizer se quebrou o comportamento. Apps gerados por IA muitas vezes “funcionam” porque ninguém checa casos de borda, não porque o código é seguro.

Congele o comportamento atual com um build que rode do mesmo jeito sempre. Adicione alguns checks de fumaça que cubram os caminhos principais: login, carregar uma página chave, submeter um formulário e chamar um endpoint de API. Mantenha-os simples, mas repetíveis.

Depois, aplique a strictness em fatias contidas. O objetivo é reduzir bugs em runtime sem transformar tudo numa refactor gigantesco.

1. Baseie o app atual: faça o tsc rodar no CI (ou localmente) e garanta que o projeto builda limpo no estado atual. Adicione um pequeno script de smoke ou um checklist manual que você execute em 2 minutos.
2. Limite a strictness a uma área segura primeiro: aplique configurações mais rígidas a uma única pasta (uma feature nova, um pacote ou um módulo) para aprender os padrões de erro sem parar todo o trabalho.
3. Corrija as fronteiras de runtime de maior risco: foque nos pontos onde dados desconhecidos entram no sistema, como respostas de API, bodies de requisição, env vars, localStorage e leituras do banco. Adicione parsing/validação e faça os tipos refletirem a realidade.
4. Expanda gradualmente com PRs pequenos: mantenha mudanças focadas (um tema por PR), como “consertar any no cliente de API” ou “adicionar checagens nulas no fluxo de auth”. PRs pequenos são mais fáceis de revisar e menos propensos a ocultar mudanças de comportamento.
5. Ative strict globalmente quando o número de erros estiver baixo: quando estiver em uma contagem manejável, habilite strict global e limpe os hotspots restantes.

Exemplo: se seu protótipo ocasionalmente crasha com “Cannot read property 'id' of undefined”, o modo strict normalmente aponta a cadeia onde user pode ser null. Consertá-lo uma vez na fronteira de auth frequentemente remove uma classe inteira de bugs.

Quais flags de strict habilitar primeiro (e por que a ordem importa)

Se você ativa tudo de uma vez em código bagunçado, geralmente recebe um muro de erros sem caminho claro de avanço. Uma abordagem melhor é ligar checagens numa ordem que mantenha correções locais e reviews compreensíveis.

Uma sequência prática para codebases bagunçadas é:

• noImplicitAny: força você a nomear tipos obscuros em vez de usar any silenciosamente
• strictNullChecks: impede os clássicos “cannot read property of undefined”
• strictBindCallApply: pega chamadas de função inválidas (comum em utilitários copiados)
• noImplicitThis: previne usos confusos de this em padrões antigos
• useUnknownInCatchVariables: torna o tratamento de erros mais seguro que assumir any

Depois de cada flag, corrija os novos erros e então avance para a próxima. Assim você mantém mudanças pequenas e aprende quais partes do app são realmente frágeis.

Se definir "strict": true depende da sua situação. Se você tem bons testes e uma base de código pequena, pode funcionar. Para apps gerados por IA com fronteiras pouco claras, habilitar flags uma a uma geralmente é mais seguro.

Você também pode controlar a área afetada com include e exclude. Começar apenas com src/ e pular áreas problemáticas temporariamente costuma ser a diferença entre “progresso” e “travado”.

Trate algumas pastas de forma diferente:

• output gerado: exclua e verifique a origem em vez de checar o código gerado
• código de vendor: não edite; envolva com adaptadores tipados
• pastas legadas: isole e adicione tipos apenas onde tocam o código novo
• misto JS/TS: converta pontos de entrada primeiro, não todos os arquivos de uma vez

Padrões de correção que removem erros sem over-engineering

As vitórias mais rápidas vêm de consertar os mesmos poucos padrões de erro de maneira consistente.

Comece com any implícito. Adicione tipos nas fronteiras primeiro: inputs de função, tipos de retorno e tudo que cruza um módulo (cliente de API, helpers de DB, handlers de evento). Quando as bordas estão tipadas, muitos erros internos desaparecem porque o TypeScript infere mais.

Erros de null e undefined geralmente exigem menos trabalho do que parecem. Prefira narrowing a tipos complexos: cheque o valor, retorne cedo e mantenha o caminho feliz limpo. Quando um padrão faz sentido, defina-o uma vez (por exemplo, name ?? "" para exibição) em vez de espalhar asserções de non-null (!) por toda parte.

Ao lidar com JSON moldado por IA, use unknown em vez de any. unknown força uma checagem antes do uso, que é exatamente o que você quer para payloads não confiáveis.

Correções práticas que você pode aplicar rápido

• Tipar entradas e saídas primeiro (funções de API, utilitários, componentes), depois preencher internamente apenas onde os erros persistirem.
• Reduzir valores nulos com if (!value) return ... e pequenos guards como typeof x === "string".
• Usar unknown para JSON e resultados de parse, então estreitar com checagens simples antes de ler propriedades.
• Para respostas de API, valide ou estreite só o que você precisa em vez de confiar em toda a forma do payload.

React e formulários são pontos comuns de dor. Tipar eventos (React.ChangeEvent<HTMLInputElement>), manter tipos de state consistentes e definir props de componentes explicitamente. Um tipo correto de evento pode eliminar muitos erros a jusante.

Guardrails: evite que a strictness volte a afrouxar

Ativar a strictness é só metade do trabalho. O difícil é mantê-la ativa quando o próximo “conserto rápido” é tentador, sobretudo em código gerado por IA onde é fácil encobrir um problema com any.

Defina guardrails que tornem o caminho seguro o mais fácil. Você não precisa de um conjunto enorme de regras. Comece com algumas que refletem como seu time costuma quebrar tipos:

• lint para proibir any e asserções de tipo “inseguras” (as unknown as X) exceto em poucos arquivos permitidos
• sinalizar promises soltas para que erros async não sejam ignorados
• exigir tipos de retorno explícitos em fronteiras chave (handlers de API, auth, acesso a dados)
• banir // @ts-ignore a menos que inclua motivo e um comentário de expiração
• vigiar soluções para noUncheckedIndexedAccess que escondam casos reais de null

Mantenha exceções visíveis. Se um arquivo precisa ficar solto por uma semana, marque e rastreie em vez de deixar o “temporário” virar permanente.

Adicione uma porta simples no CI: builds falham se novos erros TypeScript aparecerem. Durante uma migração em etapas, a versão mais fácil é escopar checagens para a pasta que você está apertando primeiro e depois alargar com o tempo.

Você também pode adicionar “type tests” leves para formas que importam. São checagens em tempo de compilação que protegem estruturas de dados chave, como “uma Session deve incluir userId” ou “a resposta de /me inclui email e role.” Mantenha-os pequenos.

Por fim, reduza duplicação criando uma pequena pasta de tipos compartilhados para forms que o app reinventa: User, Session, Role, ApiError. Quando esses tipos vivem num lugar só, o trabalho de strictness fica consistente e código gerado no futuro tem um alvo claro para corresponder.

Erros comuns que travam migrações (e como evitá-los)

Projetos que migram para strict travam quando a equipe cala o compilador, mas não confia no comportamento em runtime. O objetivo não é “fazer os erros sumirem”; é menos bugs em produção enquanto você aperta os tipos.

A maneira mais rápida de perder essa confiança é silenciar o compilador em vez de consertar a causa.

Atalhos que se voltam contra você

• Substituir correções reais por asserções as. Se você está escrevendo as any ou as SomeType repetidamente, pare e pergunte o que o valor pode ser em runtime. Valide ou estreite.
• Usar o operador de não-nulo (!) em todo lugar. Isso transforma avisos de compilação em crashes em runtime, especialmente em torno de estado de auth, dados async e env vars opcionais.
• Construir unions gigantes para modelar inputs bagunçados. Podem estar “corretos”, mas se ninguém consegue ler, eles apodrecem. Normalize dados na fronteira, depois use uma forma interna limpa.
• Alterações de tipagem que também mudam comportamento. Pequenas edições como trocar || por ??, alterar defaults ou reordenar checagens podem mudar saídas. Separe edits de tipagem de edits lógicos para que reviews fiquem claros.
• Migrar tudo num PR massivo. Parece eficiente até que um arquivo difícil bloqueie todo o merge. Divida o trabalho em fatias que você consegue concluir.

Um hábito prático: sempre que você adicionar um cast ou !, deixe uma nota e tente removê-lo antes do próximo marco. Se não der para remover, provavelmente você precisa de uma checagem de runtime real.

Um exemplo rápido

Suponha que um fluxo de signup gerado por IA lê req.body.email e você silencia erros com as string e email!.trim(). Compila, mas um payload vazio agora lança. Uma correção mais segura é checar o tipo e retornar um erro claro cedo.

Checklist rápido antes de ativar o strict em escopo maior

Antes de alargar as configurações strict pelo repositório, garanta que o básico está estável. O modo strict muda o quanto você pode confiar em cada valor que percorre o app.

Se o projeto builda só num laptop ou depende de uma versão não travada do TypeScript, você vai perder tempo correndo atrás de erros que nada têm a ver com seu código.

Verificações pré-voo que mantêm rollouts previsíveis:

• O app builda limpo hoje com uma versão travada do TypeScript e o mesmo comando no CI.
• Você consegue nomear as 2 a 3 maiores fontes de bugs em runtime (frequentemente valores nulos, mismatches de resposta de API e casos de borda de auth) e sabe onde aparecem.
• Suas fronteiras principais estão tipadas, mesmo que o interior ainda esteja bagunçado: chamadas do cliente de API, camada de acesso a dados e variáveis de ambiente.
• Você consegue manter mudanças pequenas: cada PR cabe em menos de um dia e tem um tema claro.
• Você tem uma regra clara para quando any é aceitável, e é rara e documentada.

Um cenário simples ajuda: imagine seu protótipo às vezes desloga usuários após refresh. Se seu helper de auth retorna User | null mas o código a jusante trata como sempre presente, você tem crashes aleatórios. Antes de expandir strictness, confirme que existe um lugar tipado onde “user pode ser null” é tratado e o resto do app lê dali.

Exemplo: apertando um protótipo sem frear features

Um fundador herda um protótipo Lovable ou Bolt. Funciona bem localmente, mas em produção trava após login e algumas páginas mostram dados em branco. O código “funciona” até que um usuário real bata numa borda: um campo faltante, um null da API ou um número que chega como string.

Em vez de ligar strict: true em todo lugar e se afogar em erros, trate o modo strict como uma série de consertos pequenos e de alto impacto.

Comece onde os bugs em runtime mais doem: camada de API e auth. Nesse protótipo, getSession() às vezes retorna undefined, mas a UI assume que sempre existe. As checagens strict mostram isso rapidamente.

// Before
const userId = session.user.id

// After
const userId = session?.user?.id
if (!userId) throw new Error("Not authenticated")

Em seguida, vá para utilitários compartilhados, onde um conserto pode proteger muitas telas. Um exemplo comum é parsing numérico. A API envia "42", mas o app trata como número e depois faz matemática que vira NaN.

Um caminho em etapas que costuma manter o trabalho de feature andando:

• adicione strictness só aos arquivos de API/auth primeiro
• corrija os erros principais que correspondem a crashes reais
• aperte helpers compartilhados (parsing, manipulação de datas, config)
• expanda as checagens de strict para componentes de UI por último

No caminho, você vai encontrar erros típicos de código gerado: assumir que campos opcionais existem (profile.name), misturar tipos (string | number) ou retornar objetos parciais. A correção raramente é sofisticada. Adicione guards simples, corrija tipos de retorno e normalize dados na fronteira (resposta da API entra, tipos limpos do app saem).

Como “bom” depois do rollout: menos crashes em produção, regras mais claras sobre o que pode ser undefined e um pequeno conjunto de responsáveis por arquivos core (auth, cliente de API, tipos compartilhados).

Próximos passos: tenha um plano de migração claro (e ajuda, se precisar)

O modo strict funciona quando você escolhe um ritmo que consegue manter. Antes de se comprometer, decida o que significa “pronto” para sua app: menos bugs em produção, auth e tratamento de dados mais seguros, ou uma base de código que sua equipe mexe sem medo.

Se você continuar vendo os mesmos bugs “impossíveis” (logouts aleatórios, lógica de auth que muda entre ambientes, segredos acabando no repositório), isso é sinal de que as fronteiras precisam de atenção. Outro alerta é arquitetura spaghetti: arquivos que fazem tudo, sem separação clara, e correções de tipo que se espalham por dezenas de módulos não relacionados.

Se você herdou um protótipo gerado por IA e quer um par de olhos externo, FixMyMess (fixmymess.ai) foca em pegar apps construídos por IA e torná-los prontos para produção diagnosticando a base, reparando lógica, endurecendo segurança, refatorando áreas inseguras e preparando deploys. Um passo prático inicial é uma auditoria de código gratuita para obter um plano de migração em etapas sem adivinhar onde começar.