Simon Willison Cita D. Richard Hipp, e a Analogia com SQL Desafia Previsões sobre Empregos em IA

Simon Willison destacou a analogia de D. Richard Hipp com SQL em 29 de julho, contrapondo uma referência histórica diretamente às previsões de que a IA eliminará os programadores. O argumento de Hipp começa com uma transformação anterior no trabalho. O SQL automatizou tarefas antes realizadas por meio de programas personalizados de processamento de dados, mas a programação sobreviveu e se expandiu em outras formas.

A publicação é curta, mas seu momento importa. Sistemas de programação com IA agora geram funções, testes, consultas, documentação e, às vezes, alterações coordenadas em repositórios. Esse avanço incentivou uma afirmação mais forte: quando as pessoas puderem descrever software em linguagem comum, as organizações precisarão de muito menos programadores.

Hipp oferece um modelo menos dramático. Novas abstrações reduzem o custo de expressar certas instruções e, em seguida, deslocam o esforço humano para especificação, verificação, arquitetura e manutenção. O SQL não encerrou a programação. Ele mudou quais problemas justificavam código personalizado e quais poderiam ser delegados a um mecanismo de banco de dados.

Essa analogia não prova que a IA seguirá o mesmo caminho. Modelos de linguagem de grande porte produzem resultados probabilísticos, enquanto um banco de dados executa SQL sob regras definidas. Ainda assim, a comparação oferece um teste útil para afirmações sobre carreiras em software: uma ferramenta remove o trabalho de engenharia ou o realoca para outra camada?

Simon Willison Transforma uma Citação em um Argumento sobre o Mercado de Trabalho

A notícia não é um novo recurso do SQLite nem um produto de IA. É uma referência histórica mais precisa para avaliar afirmações sobre automação.

Em sua publicação de 29 de julho, Simon Willison citou D. Richard Hipp ao descrever como o trabalho com dados mudou quando o SQL se tornou disponível. Antes do SQL, as organizações frequentemente pagavam programadores para criar software procedural que pesquisava, combinava, filtrava e resumía grandes conjuntos de dados.

Hipp identificou esses profissionais, com certa simplificação, como programadores COBOL. O SQL permitiu que um usuário especificasse um resultado desejado por meio de uma consulta compacta. O mecanismo do banco de dados então gerava ou selecionava grande parte da lógica de execução que antes estava contida em programas personalizados.

A frase-chave na comparação de Hipp é que os programadores não desapareceram. Seus empregos mudaram.

Essa distinção parece modesta, mas atinge uma das maiores premissas por trás das atuais previsões sobre a força de trabalho de IA. Muitas previsões tratam a produção de código como a unidade definidora do trabalho de programação. Se o software consegue produzir código, segue o raciocínio, o profissional que antes o digitava se torna desnecessário.

O SQL sugere que volume de código e valor de engenharia não são a mesma coisa. Uma consulta declarativa pode substituir muitas linhas de código procedural de manipulação de dados. Ainda assim, alguém precisa definir os dados, decidir o que o resultado significa, gerenciar permissões, testar casos extremos, monitorar o desempenho e responder quando os requisitos entram em conflito.

Programação declarativa significa especificar o resultado que um sistema deve produzir sem detalhar cada etapa de execução. O SQL tornou-se o principal exemplo porque os usuários informam quais dados desejam. Um planejador de consultas escolhe como o banco de dados deve recuperá-los.

Hipp já enfatizou essa distinção antes. Em um perfil sobre bancos de dados, ele argumentou que muitos desenvolvedores subestimam quanto trabalho uma linguagem declarativa pode economizar. Ele apontou códigos de aplicação que realizam manualmente junções que o banco de dados poderia processar.

Essa observação se conecta diretamente à programação com IA. Um desenvolvedor agora pode pedir a um assistente que implemente um recurso sem inserir manualmente cada instrução. O pedido comprime o esforço visível, assim como uma consulta SQL comprime operações procedurais sobre dados.

A compressão é real. O desaparecimento da responsabilidade, não.

Um usuário de SQL continua responsável por solicitar o resultado correto. Um desenvolvedor assistido por IA continua responsável por determinar se o software gerado corresponde ao comportamento pretendido. Em ambos os casos, a interface sobe de nível enquanto decisões importantes permanecem com as pessoas.

A seleção de Willison dá à analogia de Hipp um significado mais amplo. Ela transforma um comentário sobre a história do SQL em uma resposta à ideia de que a programação em linguagem natural cria automaticamente um futuro sem programadores.

A publicação também evita uma conclusão anti-IA simplista. Hipp não está argumentando que a automação não realiza nada. O SQL claramente eliminou a necessidade de escrever certos programas à mão. A analogia aceita ganhos substanciais de produtividade, ao mesmo tempo que rejeita uma ligação direta entre produtividade e extinção ocupacional.

Essa é a tensão central do acontecimento. A mesma história pode sustentar duas leituras. A automação elimina tarefas específicas, mas também torna a criação de software barata o suficiente para gerar mais demanda por software.

O SQL Mudou a Unidade de Trabalho

O SQL não preservou todas as tarefas de programação. Ele tornou muitas delas economicamente desnecessárias e deslocou a atenção para decisões de nível mais alto.

Antes dos bancos de dados relacionais e das linguagens de consulta amplamente adotadas, extrair uma nova resposta de dados empresariais podia exigir um programa dedicado. Um programador precisava entender estruturas de registros, caminhos de acesso, rotinas de ordenação, formatos de arquivos e requisitos de relatórios.

Uma pequena mudança em uma pergunta podia exigir outro programa ou uma revisão significativa. A organização pagava por um procedimento, não simplesmente por um resultado.

O SQL alterou esse arranjo. Um usuário podia descrever um resultado usando seleções, junções, agrupamento e ordenação. O banco de dados traduzia esse pedido em um plano de execução, que é o conjunto de operações usado para retornar os dados solicitados.

A analogia de Hipp condensa uma longa história técnica, como ele reconhece pelo enquadramento da citação. O COBOL não desapareceu quando o SQL chegou. Sistemas COBOL também continuaram a executar cargas de trabalho de folha de pagamento, bancos, seguros, governo e processamento de transações.

A mudança importante foi mais restrita. As organizações deixaram de precisar de um novo programa procedural para cada pergunta comum que uma consulta relacional pudesse expressar.

Essa é uma forma significativa de deslocamento de empregos no nível das tarefas. Uma ferramenta pode eliminar horas de implementação especializada sem eliminar a ocupação que contém essa tarefa.

A distinção entre empregos e tarefas frequentemente se perde nos debates sobre IA. Um emprego é um conjunto de atividades, responsabilidade, conhecimento de domínio, comunicação e decisões. A automação raramente alcança todas as partes desse conjunto no mesmo ritmo.

O SQL automatizou a execução de consultas, mas criou demanda por administração de bancos de dados, projeto de esquemas, otimização de consultas, modelagem de dados, análise, segurança e integração de aplicações. Também tornou o acesso a dados prático para muito mais equipes.

Hipp descreveu o valor duradouro do SQL por meio de três ideias: transações, abstração de dados e linguagem declarativa. Em uma entrevista sobre SQLite de 2024, ele afirmou que o modelo relacional continuava eficaz para representar muitos problemas do mundo real.

As transações garantem que operações de banco de dados relacionadas sejam concluídas sob regras controladas de consistência. A abstração de dados separa uma solicitação lógica dos detalhes de armazenamento físico. A linguagem declarativa permite que o usuário se concentre na resposta desejada.

Juntas, essas capacidades fizeram mais do que economizar teclas digitadas. Elas redistribuíram a especialização entre o programador de aplicações, o mecanismo de banco de dados, o especialista em bancos de dados e o usuário de negócios.

Os assistentes de programação com IA estão iniciando uma redistribuição semelhante, embora seu mecanismo seja diferente. Eles podem traduzir intenção em código, pesquisar repositórios desconhecidos, propor testes, explicar funções legadas e produzir rascunhos de migrações ou documentação.

À medida que essas capacidades melhoram, as equipes gastarão menos tempo escrevendo código rotineiro de implementação. Esse resultado não deve ser suavizado. Algumas tarefas de nível inicial, atribuições de manutenção e trabalhos terceirizados de programação enfrentarão pressão direta.

No entanto, o esforço economizado não informa o que acontece com o emprego total. Custos de produção menores podem reduzir a demanda por trabalho quando a quantidade de produção desejada permanece fixa. Eles podem aumentar a demanda por trabalho quando uma produção mais barata viabiliza muito mais projetos.

O software raramente se comportou como um mercado fixo. Equipes mantêm longas listas de pendências, adiam ferramentas internas, toleram fluxos de trabalho manuais e postergam integrações porque a capacidade de engenharia é limitada. Se a IA reduzir o custo desses projetos, as organizações poderão construir mais deles.

O precedente do SQL, portanto, apresenta três efeitos ao mesmo tempo:

• Substituição: o sistema realiza trabalho antes atribuído a um programador.

• Expansão: custos menores tornam economicamente viável trabalho adicional com software e dados.

• Recomposição: as funções restantes dão maior peso a julgamento, projeto, revisão e conhecimento de domínio.

Esses efeitos não se equilibrarão da mesma maneira em todas as empresas. Uma empresa com produto estável e roadmap fixo poderia usar IA para reduzir contratações. Uma empresa em crescimento poderia manter o quadro de pessoal estável enquanto lança mais recursos. Uma pequena organização poderia começar a desenvolver software que antes não podia pagar.

Essa variação explica por que afirmações amplas sobre “o programador” são frágeis. A automação alcança tarefas específicas dentro de organizações específicas. Seus efeitos sobre o emprego dependem de demanda, orçamentos, risco e da quantidade de novo trabalho criada.

O Verdadeiro Oponente É a Automação de Tarefas Versus a Eliminação de Empregos

O principal desafio de Hipp não é direcionado às ferramentas de programação com IA. Ele é direcionado à premissa de que automatizar a geração de código elimina toda a função de engenharia.

Uma função gerada pode parecer trabalho concluído. Ela chega rapidamente, compila em casos favoráveis e pode passar nos testes fornecidos ao modelo. Esse resultado visível incentiva as pessoas a equiparar implementação a todo o ciclo de vida do software.

A engenharia de produção inclui muito mais. Alguém precisa transformar uma solicitação ambígua em comportamento preciso. Essa pessoa deve resolver conflitos entre partes interessadas, identificar requisitos ausentes, escolher limites do sistema, proteger dados e decidir quais falhas são aceitáveis.

A equipe também precisa manter o resultado depois que seu contexto original muda. Dependências recebem atualizações. Regulamentos mudam. Usuários descobrem fluxos de trabalho inesperados. Atacantes procuram vulnerabilidades. Os volumes de dados crescem além das premissas incorporadas à primeira versão.

A IA pode ajudar em cada atividade, mas a assistência não transfere automaticamente a responsabilidade. Quando código gerado causa um incidente de segurança, clientes e reguladores não tratam o modelo como o operador responsável.

A comparação com SQL torna esse limite mais fácil de enxergar. Um mecanismo de banco de dados pode escolher um plano de execução, mas não decide se uma consulta responde à pergunta de negócio correta. Ele não consegue determinar se uma junção tecnicamente válida cria uma métrica enganosa.

Da mesma forma, um assistente de IA pode produzir uma implementação sem saber se a especificação reflete as necessidades reais da organização. Quanto mais a implementação se torna automatizada, mais a qualidade da especificação determina o resultado.

Isso cria uma inversão importante. A linguagem natural parece mais fácil do que o código, mas a linguagem comum tolera ambiguidades que o software não pode ignorar com segurança.

“Adicionar tratamento automático de impostos” parece claro até que o sistema precise considerar jurisdições, isenções, reembolsos, regras de arredondamento, datas de vigência e dados incompletos de clientes. Um engenheiro humano tradicionalmente descobre e formaliza esses detalhes durante o projeto e a implementação.

Se um agente de IA escreve o código, essas questões não desaparecem. Elas migram para prompts, especificações, testes, documentos de política, sessões de revisão ou incidentes em produção.

Uma análise de junho de 2026 sobre o futuro sem código apresentou um argumento relacionado. Ela descreveu a IA como mais uma etapa na abstração da programação, observando que especificações precisas ainda funcionam como código, independentemente do seu formato superficial.

É aqui que a analogia de Hipp com SQL é mais forte. SQL funciona porque seu escopo declarativo é limitado. O banco de dados entende tabelas, relações, predicados, agrupamento, ordenação e transações sob semântica formal.

Os requisitos gerais de software não chegam com limites equivalentes. Eles misturam comportamento técnico com políticas, estética, incentivos organizacionais, obrigações legais e pressupostos que as partes interessadas talvez nunca explicitem.

Um agente de programação com IA pode inferir detalhes ausentes. Essa flexibilidade é útil, mas também introduz riscos. Um requisito inferido pode parecer plausível e, ainda assim, estar errado.

Os mecanismos de SQL também produzem planos indesejáveis, especialmente quando estatísticas, índices ou pressupostos de carga de trabalho são inadequados. Sua saída, porém, continua sendo regida por semântica determinística de banco de dados. Um modelo de linguagem de grande porte pode gerar implementações diferentes a partir de prompts semelhantes e pode inventar APIs ou pressupostos.

Portanto, programação com IA não é simplesmente “SQL para todo software”. Trata-se de uma interface mais flexível e ambiciosa.

A analogia funciona no nível econômico porque ambas as tecnologias comprimem o esforço de implementação. Ela se enfraquece no nível da confiabilidade porque a geração de código geral tem um espaço de saída muito maior.

Essa diferença aumenta o valor da verificação. Desenvolvedores precisam de testes que cubram comportamentos relevantes, práticas de revisão que examinem segurança e manutenção, e observabilidade que revele falhas após a implantação.

As equipes também precisam de contexto duradouro. Requisitos, decisões arquiteturais, históricos de incidentes e restrições de domínio devem permanecer acessíveis quando um agente ou engenheiro altera um sistema. Uma base de conhecimento técnico pesquisável pode apoiar esse trabalho, especialmente quando mudanças geradas abrangem repositórios desconhecidos.

A função resultante pode envolver menos digitação manual de código. Ainda assim, ela se assemelha à engenharia porque exige formalização, validação, escolhas e responsabilidade.

Onde a Analogia com SQL Falha

SQL oferece um precedente útil sobre trabalho, mas não pode determinar a velocidade com que a IA melhorará nem quantas posições de programação as empresas manterão.

Analogias históricas selecionam semelhanças enquanto ocultam diferenças. SQL foi projetado para uma família específica de operações de dados. Sua sintaxe e semântica criaram um contrato estável entre a pessoa que formula uma consulta e o banco de dados que a executa.

Sistemas de programação com IA operam em linguagens, frameworks, repositórios, interfaces e domínios de negócio em constante mudança. Eles frequentemente encontram documentação incompleta e convenções contraditórias. Sua tarefa não é apenas otimização dentro de um modelo formal.

Esse escopo mais amplo pode tornar a IA economicamente mais significativa que SQL. Um agente que navega por um repositório, edita vários serviços, executa testes e responde a falhas cobre uma parte maior do fluxo de desenvolvimento do que um planejador de consultas cobre.

O mesmo escopo também pode dificultar uma automação confiável. O sucesso em um benchmark delimitado não comprova desempenho seguro dentro de um sistema de produção de longa duração.

Uma alteração gerada pode passar em testes unitários enquanto viola uma premissa operacional não documentada. Ela pode repetir um padrão inseguro já presente no repositório. Pode resolver o ticket visível enquanto aumenta os custos futuros de manutenção.

Desenvolvedores humanos também cometem esses erros. A questão relevante é se a IA altera sua frequência, detectabilidade e escala.

A velocidade pode amplificar tanto resultados bons quanto ruins. Se uma equipe produz cinco vezes mais alterações, até mesmo uma taxa menor de erros por alteração pode gerar mais trabalho total de revisão. Por outro lado, testes automatizados robustos poderiam permitir que a equipe ampliasse a produção sem aumentar as falhas.

Essa incerteza enfraquece previsões confiantes dos dois lados. É prematuro declarar os empregos de programação seguros porque SQL não os eliminou. É igualmente prematuro inferir uma eliminação em massa a partir de demonstrações impressionantes de geração de código.

Os próprios comentários públicos de Hipp mostram uma posição cautelosa sobre programação totalmente autônoma. Na entrevista de 2024, ele descreveu a IA como útil, porém superestimada, e afirmou que a programação assistida parecia mais provável do que a geração de código completamente automática.

Essa previsão continua sendo um ponto de vista, não um resultado medido. As capacidades de IA e os designs de produtos continuam mudando, enquanto as organizações ainda aprendem a implantar agentes em processos de desenvolvimento controlados.

Categorias de emprego também podem sobreviver enquanto se tornam menores ou mais difíceis de acessar. O setor bancário ainda emprega especialistas em COBOL, mas isso não significa que COBOL ofereça a mesma trajetória profissional que oferecia antes. Uma tecnologia pode preservar expertise crítica enquanto reduz o número de pessoas que realizam trabalho rotineiro.

Funções júnior merecem atenção especial. Engenheiros seniores frequentemente aprenderam por meio de pequenas correções de bugs, integrações simples, escrita de testes e trabalho supervisionado em funcionalidades. Essas são justamente as tarefas que os atuais assistentes de programação executam bem.

Se as empresas automatizarem esse trabalho sem redesenhar o treinamento, poderão enfraquecer o fluxo que forma futuros engenheiros seniores. SQL criou novas especialidades, mas não respondeu como uma equipe com forte uso de IA deve desenvolver discernimento entre pessoas que já não praticam a implementação básica com tanta frequência.

Outra incerteza diz respeito ao comportamento organizacional. Ganhos de produtividade não precisam se traduzir em mais software. Executivos podem capturá-los com equipes menores, metas de produção mais altas, cronogramas mais curtos ou alguma combinação disso.

A distribuição importará tanto quanto a capacidade técnica. Desenvolvedores poderiam usar IA para controlar sistemas maiores e enfrentar problemas negligenciados. Também poderiam enfrentar cargas de trabalho intensificadas porque a gestão trata toda economia de tempo como capacidade extra permanente.

A analogia de Hipp não resolve esse conflito. Ela o esclarece.

A questão não é se a IA automatiza tarefas de programação. Ela já automatiza. A questão é quem controla o tempo economizado, quais responsabilidades permanecem humanas e se a crescente demanda por software absorve o trabalho deslocado.

A Programação com IA Muda as Habilidades que as Empresas Compram

À medida que a implementação se torna mais barata, as organizações atribuem mais valor a pessoas capazes de definir resultados corretos e detectar erros convincentes.

A transição para SQL recompensou pessoas que entendiam modelos de dados e questões de negócio, não apenas aquelas que conheciam a sintaxe de consultas. A programação com IA deve gerar um prêmio semelhante para compreensão de domínio, design de sistemas, testes e julgamento operacional.

A escrita de prompts, por si só, dificilmente se tornará a habilidade substituta duradoura. Prompts são interfaces, e interfaces se tornam mais fáceis à medida que os produtos amadurecem. A capacidade mais escassa é reconhecer quando uma resposta plausível não atende ao requisito real.

Para desenvolvedores, isso significa entender o sistema além do diff gerado. Eles precisam rastrear o movimento dos dados, identificar fronteiras de confiança, avaliar modos de falha e conectar mudanças no código às consequências para os usuários.

Ler código pode se tornar mais importante, mesmo que escrevê-lo se torne menos central. Engenheiros precisam inspecionar saídas desconhecidas e determinar se elas se encaixam nas convenções locais. Também precisam de conhecimento fundamental suficiente para reconhecer defeitos sutis.

Os testes também mudam. Testes gerados podem ampliar a cobertura, mas um modelo pode reproduzir o mesmo mal-entendido tanto no código quanto nos testes. As equipes precisam de critérios de aceitação independentes e testes baseados no comportamento desejado, não apenas na implementação gerada.

A arquitetura se torna outro ponto de pressão. Sistemas de IA podem propor padrões conhecidos, mas um padrão conhecido nem sempre é apropriado. Decisões sobre limites de serviços, consistência, latência, retenção de dados e complexidade operacional refletem restrições específicas.

Especialistas de domínio ganham influência porque podem fornecer um contexto que o modelo não possui. Um fluxo de trabalho de saúde, sistema de reconciliação financeira ou controlador industrial contém regras que não podem ser recuperadas de forma confiável a partir de dados genéricos de treinamento.

Isso não significa que todo desenvolvedor se torne arquiteto. Significa que o centro econômico da função se desloca para selecionar, restringir e validar trabalho automatizado.

Alguns empregos se tornarão mais estreitos. As equipes podem precisar de menos pessoas para conversões repetitivas, estruturação básica de interfaces ou geração rotineira de testes. Prestadores que vendem volume de implementação podem enfrentar pressão sobre preços quando clientes conseguem produzir internamente primeiros rascunhos aceitáveis.

Outros empregos se expandirão em torno de integração e garantia. As organizações precisam de pessoas que conectem sistemas de IA a repositórios privados, controlem permissões de ferramentas, avaliem resultados, mantenham infraestrutura de desenvolvimento e investiguem falhas.

A modernização de sistemas legados ilustra o efeito misto. Pesquisadores da IBM descreveram o uso de modelos treinados em padrões corporativos de COBOL para apoiar a tradução para Java. Seu trabalho de modernização ainda depende da compreensão de CICS, Db2, VSAM, IMS e do comportamento de negócio incorporado em sistemas antigos.

Tradução não equivale a substituição. Um sistema pode conter décadas de decisões não documentadas. Produzir sintaxe Java não estabelece que o novo programa preserve todo comportamento exigido.

O programador experiente de COBOL pode escrever menos rotinas de migração manualmente. O conhecimento dessa pessoa se torna mais importante durante a validação porque o modelo não possui contexto histórico e institucional.

SQL criou uma divisão comparável. O mecanismo de consultas automatizou a seleção de algoritmos, mas cargas de trabalho difíceis ainda exigiam pessoas que entendessem esquemas, índices, estatísticas e comportamento de aplicações.

A programação com IA, portanto, pressiona os desenvolvedores a avançarem sem perder contato com a implementação. Um revisor que não consegue raciocinar sobre código se torna dependente do mesmo sistema que está sendo revisado.

As empresas também enfrentam um desafio de gestão. Elas precisam distinguir produção mais rápida de código de entrega mais rápida de resultados confiáveis. Se revisões, verificações de segurança, decisões das partes interessadas ou processos de implantação continuarem limitados, o código gerado pode se acumular sem melhorar o valor para o cliente.

Métricas baseadas em linhas de código ou tickets concluídos se tornam ainda menos úteis. As equipes devem examinar o tempo de entrega, defeitos que escapam, frequência de incidentes, retrabalho e se as funcionalidades lançadas resolvem o problema pretendido.

A vantagem duradoura pertence às equipes que combinam automação com especificações claras e verificações independentes. Apenas adicionar um assistente de IA a um processo existente não revelará para onde a responsabilidade deve migrar.

O Que a Citação de Simon Willison Torna Importante Observar

A próxima fase deve ser avaliada por evidências sobre autonomia, demanda por software e formação de carreira, não pelo volume de código gerado.

O primeiro sinal é se agentes de IA conseguem concluir trabalho de produção sustentado com intervenção humana limitada. Demonstrações curtas de programação já não são suficientes. O teste mais rigoroso envolve mudanças em múltiplos arquivos, requisitos ambíguos, restrições de implantação, revisão de segurança e manutenção após o lançamento.

Se os agentes lidarem repetidamente com esses fluxos de trabalho com pouco retrabalho e poucos defeitos que escapam, a analogia de Hipp com SQL se enfraquece como previsão de substituição limitada de tarefas. A IA estaria automatizando uma parcela maior do conjunto de atividades de engenharia.

Se a revisão humana continuar sendo a principal restrição, a analogia se fortalece. O trabalho terá migrado para supervisão e especificação, em vez de desaparecer.

O segundo sinal é a demanda total por software. As empresas devem revelar se os ganhos de produtividade geram equipes menores, reduzem filas de trabalho pendente com equipes estáveis ou ampliam projetos que antes eram inviáveis financeiramente.

Os dados de contratação, por si só, serão difíceis de interpretar. Uma empresa pode desacelerar as contratações enquanto aumenta a produção, ou reduzir vagas para profissionais juniores enquanto disputa intensamente engenheiros experientes. A composição do emprego dirá mais do que o número principal.

Observe quais projetos recebem financiamento. O crescimento de ferramentas internas, software para pequenas empresas, integrações personalizadas e melhorias de acessibilidade reforçaria o efeito de expansão observado após abstrações anteriores. A concentração dos ganhos em produtos já existentes sustentaria uma substituição mais forte.

O terceiro sinal é a estrutura do trabalho de nível inicial. As organizações precisam de uma forma crível de formar desenvolvedores quando os agentes executam muitas tarefas tradicionalmente atribuídas a iniciantes.

Evidências de fluxos de trabalho de IA supervisionados, programas de aprendizagem mais robustos e avaliações baseadas em depuração ou raciocínio sobre sistemas mostrariam que a profissão está se adaptando. Um colapso prolongado nas contratações de profissionais juniores, sem treinamento substituto, sugeriria uma ruptura mais profunda nas carreiras.

Esses sinais devem surgir ao longo do tempo, não a partir de um único lançamento ou benchmark. Os sistemas de emprego se ajustam mais lentamente do que as capacidades dos modelos. Orçamentos, regras de compras, requisitos de segurança e arquiteturas legadas limitam a velocidade com que o potencial técnico se transforma em prática operacional.

A publicação de Simon Willison é importante porque Hipp oferece uma pergunta inicial melhor. Em vez de perguntar se a IA consegue escrever código, pergunte qual camada do trabalho se torna declarativa e qual responsabilidade humana permanece acima dela.

O SQL tornou desnecessária uma enorme quantidade de trabalho procedural com dados. Também viabilizou sistemas de software maiores, acesso mais amplo a dados e novas especialidades técnicas. Ambos os resultados foram verdadeiros.

A programação com IA pode seguir esse padrão misto, mas provocar uma disrupção maior. A implementação rotineira perderá valor. Julgamento preciso, conhecimento de domínio, verificação e responsabilidade ganharão valor.

Os desenvolvedores devem responder testando onde a IA realmente elimina trabalho e onde ela apenas esconde complexidade. As equipes devem documentar as restrições que o código gerado precisa respeitar e, em seguida, medir os resultados após a implantação.

A próxima geração de programadores se parecerá com usuários de SQL que comandam um mecanismo de execução mais capaz ou com revisores que supervisionam sistemas que já não compreendem por completo? A resposta dependerá de quão deliberadamente as empresas preservarem a verificação, o aprendizado e a responsabilização à medida que a automação avança.