DOS, Windows, Web e IA: estamos entrando em um quarto paradigma?

TL;DR  —  Resumo rápido do post:

• Eu atravessei três paradigmas programando: DOS, Windows e Web — em cada um, a função do desenvolvedor mudou.
• A IA está trazendo o quarto: parte do raciocínio, da implementação, dos testes e da documentação passa a ser delegada.
• Mas delegar não é abdicar: arquitetura, regra de negócio, prioridade e risco continuam sendo humanos.
• A migração do nosso Web Forms 4.8 para .NET 10 e Angular é o laboratório real dessa transição.

~ 8 min de leitura · 1335 palavras

DOS: o programador era o framework

Eu comecei em Clipper sobre DOS nos anos 90. Não tinha componente: eu escrevia o loop de leitura do `.DBF`, o controle de bloqueio de registro, a validação, a tela. O sistema inteiro passava pelas minhas mãos, linha por linha. Quando o `BROWSE()` travava, era meu código. Quando o índice corrompia, era meu problema.

A vantagem dessa miséria: não havia distância entre a decisão e a consequência. Se eu modelava mal um arquivo, o cliente reclamava no mesmo dia. Aprendi a programar porque o custo do erro era imediato e inescapável.

Windows: componentes, eventos, bibliotecas

A transição para Windows mudou a unidade de trabalho. Eu não escrevia mais o loop de mensagem — eu assinava um evento `Click` de um botão que o sistema operacional entregava. O VCL, depois o WinForms, trouxeram componentes prontos: grid, impressão, controles visuais. A orientação a objetos deixou de ser teoria e virou o dia a dia: herança de formulários, classes base, reutilização de bibliotecas.

O trade-off apareceu cedo. Eu ganhava velocidade e perdia controle: quando o componente tinha um bug, eu gastava dias contornando comportamento que não via o código. Comecei a depender de coisas que eu não tinha escrito. Essa dependência era assustadora em 2000 — e é treinamento para o que veio depois.

Web: a responsabilidade se divide

A Web distribuiu o que o DOS concentrava. Front-end separado do back-end, back-end separado do banco, banco separado do cache, tudo amarrado por APIs HTTP. Cada parte com linguagem, time de decisões e modo de falhar próprio. Programar deixou de ser escrever um sistema e passou a ser orquestrar uma arquitetura: definir contrato de API, decidir o que roda no cliente e o que roda no servidor, garantir que um `POST` que passou no front também seja validado no back.

Nesse paradigma, a habilidade nova não era técnica — era de fronteira. Quem entendia bem uma única camada sofria; quem entendia as fronteiras entre camadas entregava. Foi assim que eu passei anos: Web Forms, depois APIs, depois Angular, cada camada exigindo uma mentalidade diferente.

IA: quando a unidade de trabalho deixa de ser código e vira objetivo

E agora a quarta transição. A diferença entre usar IA como autocomplete e trabalhar com agentes é a mesma diferença entre digitar mais rápido e delegar uma tarefa. Autocomplete acelera a escrita de código que eu já decidi. Agente recebe um objetivo — “migre esse WebForm para componente Angular com esse comportamento” — e produz código que eu não escrevi.

Não é incremental. É a primeira vez em trinta anos que o desenvolvedor não é quem escreve tudo. Parte da implementação, parte dos testes, parte da documentação nasce fora da minha cabeça e entra no repositório sem passar pelos meus dedos. Isso muda a função.

No nosso laboratório — a migração de Web Forms 4.8 para .NET 10 e Angular — isso é concreto. Uma migração de WebForm para Angular em 2019 era uma semana de trabalho mecânico: traduzir code-behind para service, grid para componente, postback para endpoint. Hoje eu divido a tarefa entre agentes: um faz o levantamento do que o WebForm realmente faz (coisa que ninguém lembra), outro gera o endpoint .NET, outro scaffolding do componente Angular, outro escreve os testes. Eu reviso cada saída, testo a integração, decido o que entra. A semana virou um dia. Mas o dia continua sendo meu — arquitetura, regra de negócio, prioridade, risco e validação não delegam.

O papel novo: contexto, revisão, orquestração

O que substitui o tempo de digitação é trabalho que antes não existia como disciplina: dar contexto. Um agente sem contexto gera código plausível e errado — usa `var` onde o padrão do projeto é tipo explícito, inventa uma validação que conflita com a regra do sistema, ignora uma constraint do banco. Meu trabalho hoje é garantir que o agente saiba o que eu sei: padrão de nomenclatura, estrutura do projeto, regra de negócio, o que já existe e não pode ser duplicado.

E revisar. Código gerado por IA tem uma armadilha específica: parece correto. Sintaxe impecável, nome de variável decente, comentário educado. O bug está na semântica — no caso de borda, na regra de negócio que o agente não conhecia. Aceitar código que eu não entendo é a mesma armadilha de aceitar componente de terceiro sem conhecer comportamento, só que em escala muito maior e com uma diferença cruel: o componente de terceiro tinha documentação e histórico; o código gerado, não.

A regra que eu aplico: se eu não consigo explicar o que aquele código faz, ele não entra em produção. Teste automatizado ajuda, mas não substitui leitura. Teste passa no caminho feliz e falha no caminho que ninguém imaginou — e é justamente o caminho que ninguém imaginou que gera incidente em produção.

Produtividade sobe. Responsabilidade não diminui

IA aumenta produtividade real: tarefas mecânicas que tomavam dias viram horas, boilerplate desaparece, testes que ninguém escrevia passam a existir. Mas produtividade não elimina responsabilidade — ela concentra. Quando eu era o único escrevendo cada linha, o código já chegava com minha decisão embutida. Quando o agente escreve, minha decisão precisa aparecer antes (no objetivo e no contexto) e depois (na revisão e no merge). A responsabilidade se desloca do ato de escrever para o ato de decidir o que será escrito e validar o que foi escrito.

Quem não entende essa mudança vive dois extremos igualmente ruins: ou rejeita a IA e perde produtividade sem ganhar qualidade, ou aceita tudo e vira operador de um sistema que não compreende. O caminho do meio é o trabalho de verdade do desenvolvedor em 2026: definir bem o objetivo, dar contexto suficiente, revisar com rigor, testar o que importa, assinar o resultado com o próprio nome.

O que não delega

Algumas coisas continuam sendo minhas, e continuam sendo o que separa software que funciona de software que “compila”:

• Arquitetura. O agente sugere camadas, mas a decisão de onde vai cada coisa é minha — ela tem custo por anos.
• Regra de negócio. O agente não sabe que cliente inativo não pode emitir NFe. Eu sei, ou descubro com quem sabe.
• Prioridade. O que migra primeiro não é problema técnico, é decisão de negócio.
• Risco. Aceitar uma solução é assumir o risco dela. Assinatura é individual.
• Validação final. Teste automatizado cobre o que eu imaginava. Experiência cobre o que ninguém imaginava.

Então, a IA é só mais uma ferramenta?

Não. Uma ferramenta espera que eu a use para fazer o que eu decidi. Um agente decide, dentro do escopo que eu dou, como fazer — e às vezes surpreende com uma abordagem que eu não teria pensado. Isso é diferente de ferramenta, é próximo de colega júnior muito rápido: produz muito, precisa de direção e não tem noção do risco.

A função do desenvolvedor está mudando, sim — mas não desaparece. Passa a ser menos sobre digitar código e mais sobre definir, contextualizar, revisar, orquestrar. No quarto paradigma, saber programar continua essencial: é o que me permite revisar com critério, detectar o bug semântico, recusar a solução elegante e errada. O que muda é que saber orientar, contextualizar e revisar passa a ser igualmente importante. Quem só sabe programar vai ser substituído por quem programa e sabe delegar. E quem delega sem saber programar vai descobrir o preço em produção — na madrugada, com o cliente do outro lado da linha, perguntando por que o sistema não funciona.

Leitura relacionada

• O que um programador DOS sabia e vale para a Web — os princípios que atravessaram os três primeiros paradigmas e continuam valendo no quarto.
• Programar ficou mais fácil ou apenas trocamos dificuldades? — a produtividade dos agentes vista pelo mesmo prisma de carreira.
• Do DOS à Web: mudou tudo, menos o problema que o software precisa resolver — a tese de que regra de negócio atravessa tecnologia, agora aplicada à delegação.