Senior developer em 2026: quatro veteranos sobre o que a IA deixa aos humanos

Quando um jornalista pergunta a quatro engineers sénior com dez ou mais anos de experiência em produção o que os mantém relevantes em 2026, espera-se quatro respostas diferentes. Recebe-se uma. A IA tornou as competências de codificação quase irrelevantes, o ownership não se moveu um milímetro, e o engineer que faz as duas coisas continua a receber o telefonema. A entrevista de Marko Crnjanski na ShiftMag de 24 de abril de 2026 reuniu Denis, Marina, Marko e Mario, todos com mais de 10 anos de carreira, e a convergência e a notícia. Não concordam por terem combinado as respostas. Concordam porque o trabalho subjacente mudou da mesma forma para todos os que correm código de produção em 2026.

Este texto lê as suas respostas como documento do lado do comprador e do hiring, com citações verbatim e a polémica é minha. Se está a filtrar contractors sénior, a pagar salários sénior ou a carregar um pager por um sistema que envia código gerado por IA todos os dias, esta convergência quádrupla é o seu sinal.

#Como os programadores sénior se mantêm relevantes

Marko Crnjanski, editor da ShiftMag, entrevistou quatro engineers, cada um com mais de dez anos em produção, sobre três perguntas: o que os manteve relevantes, se o sucesso a longo prazo pende para especialista ou generalista, e como as ferramentas de IA mudam as carreiras de developer. As respostas foram editadas, mas não comprimidas até ao banal. Lido de fio a pavio, o artigo lê-se menos como um painel e mais como um focus group que não sabia que o era.

Denis sobre manter-se relevante: I was always looking for ways to improve my workflow, so I could spend more time on the interesting, creative parts of the job and less on repetitive, routine tasks. I focused on really understanding problems and possible solutions, which meant building deeper knowledge rather than relying on quick fixes from the internet. Denis diz portanto que a compreensão profunda dos problemas vence as soluções rápidas da internet, porque o tempo criativo só se liberta quando a rotina já é compreendida.

Marina sobre o mesmo: Staying relevant over the years came down to curiosity and hands-on learning. I regularly read blogs and watch online conferences to keep up with new technologies, but I learned the most by trying things out through small POCs. Marina acrescenta que aprende mais com pequenos POCs feitos com as próprias mãos do que com consumo passivo de conteúdos.

Marko sobre o mesmo: For me it’s a combination of continuous learning and a strong focus on fundamentals. I always tried to explore new technologies and different domains, but with an emphasis on really understanding the core principles behind them. Marko liga aprendizagem e fundamentos: novas tecnologias, sim, mas sempre passando pelos princípios essenciais.

Mario sobre o mesmo: Talking to other people, watching what others build, and experimenting myself plus exploring open source projects, YouTube videos, and Udemy courses on 2x speed to quickly understand what’s possible with unfamiliar tools. Mario apoia-se em conversas diretas, em open source e em consumo rápido a velocidade dupla para situar rapidamente o que é possível com uma ferramenta desconhecida.

Cada um deles, perguntado em separado, voltou à mesma tríade: conhecimento profundo em vez de solução rápida, experiência hands-on de produção e aprendizagem que se move entre domínios em vez de descer por um único poço. Os quatro trabalharam ainda em stacks diferentes (Marina mais front-end, Mario desde os Linux internals para cima, Marko cross-stack, Denis mais perto do produto), o que torna a convergência mais forte e não mais fraca.

#Programador WordPress sénior em Portugal e recibos verdes

A pergunta da ShiftMag muda de textura conforme o mercado onde é feita, e o mercado português tem forma própria. Uma parte substancial do trabalho sénior de WordPress feito em Portugal não é vendida a clientes portugueses. É vendida a agências e a produtos estrangeiros, a partir de Lisboa, do Porto e cada vez mais de Braga, onde o ecossistema à volta do parque tecnológico e da universidade formou uma bolsa de developers que factura para fora sem sair do país. Ao lado disso corre o circuito interno: agências digitais que servem PME e autarquias, e um punhado de casas de produto que mantêm WordPress como camada de conteúdo à frente de outra coisa qualquer.

As três posições reagem à IA de maneiras diferentes. Na agência que serve o mercado interno, a IA comprime a parte do trabalho que era escrever o tema à mão, e o que sobra é a negociação com o cliente sobre o que o site deve fazer, que nunca foi a parte fácil. No trabalho vendido para fora, a proposta portuguesa assentava em fuso horário partilhado com o resto da Europa e em horas mais competitivas; quando a IA encolhe as horas, o que resta para vender é a revisão e o ownership, exactamente aquilo que Mario descreve.

O terceiro caso é o mais desconfortável e quase não se discute. Muitos seniores portugueses trabalham como trabalhadores independentes, a passar recibos verdes para um único cliente estrangeiro durante anos seguidos. O Código do Trabalho tem uma presunção de laboralidade construída sobre indícios: horário determinado por quem paga, equipamento fornecido por quem paga, integração na estrutura interna da empresa, prestação continuada ao mesmo destinatário. Um sénior que passa o dia a rever pull requests gerados por IA dentro do fluxo interno do cliente acumula esses indícios muito mais depressa do que um sénior que entregava projetos fechados e desaparecia até ao seguinte. A IA não mudou a lei. Mudou a forma do dia de trabalho, e é a forma do dia de trabalho que a lei observa.

Para quem contrata em Portugal, a leitura prática é simples: se o que quer comprar é revisão contínua e ownership, compre-o com o enquadramento certo desde o início, em vez de descobrir a diferença numa inspecção.

#A IA vai substituir os programadores sénior?

A linha mais forte do artigo vem de Marina: AI tools will significantly change how developers work, but I don’t see them replacing strong engineers. Instead, they will amplify those who understand what they are building. Marina diz portanto que a IA amplifica quem sabe o que constrói em vez de os substituir.

A palavra amplifier faz aqui muito trabalho. Um amplificador multiplica sinal. Multiplica também ruído. A leitura do lado do comprador é que a IA não eleva sozinha um júnior a sénior nem achata a curva de seniority. Torna-a mais inclinada. O sénior que sabe o que enviar fica mais rápido. O júnior que não sabe o que enviar fica mais rápido a enviar a coisa errada.

Denis vai mais longe, com a citação mais provocadora do texto: AI tools have made coding skills almost irrelevant. Still, other skills and practices related to quality, such as trunk-based development, TDD, continuous delivery, modularity, cohesion, DDD, etc., are more valuable than before. AI tools are a powerful amplifier, and they need guidance. Denis afirma portanto que a produção de código puro perdeu valor marginal económico, o ofício à volta cresce, e o amplificador só funciona com orientação.

Leia esta linha devagar. Ele não está a dizer que codificar não interessa. Está a dizer que o ato de produzir sintaxe válida numa linguagem conhecida caiu próximo de zero em valor económico marginal, enquanto o ofício que o rodeia (disciplina de testes, cadência de deployment, coesão arquitetural) subiu. Isto é consistente com o que recrutadores polacos disseram à No Fluff Jobs no relatório de mercado 2025-2026: os programadores são cada vez mais operadores de LLMs e arquitetos de automação, não dactilógrafos de código. O Just Join IT formula-o de forma mais direta: o prompt engineering foi tão importante quanto a programação clássica durante um ano, depois dissolveu-se no día-a-día, e o que ficou foi a capacidade de apontar a IA aos problemas que importam. O Portugal Talent Hub registou em 2025 a continuação da escassez de séniores em IT no mercado português, com a pressão a deslocar-se das stacks específicas para perfis com várias profundidades reais.

Para comércio pronto para agentes e o pilar Universal Commerce Protocol ou entregas headless WordPress com front público desacoplado, o enquadramento amplificador de Marina e a verdade operacional. A IA envia o código. O sénior decide se o código pertence a este repositório.

#Quem é responsável pelo código gerado por IA

A articulação mais limpa do lado humano da viragem da IA vem de Mario: The amount of generated code is huge, yet humans still need to review, understand, and own it. AI isn’t the one waking up when something breaks. Creating PRs with AI is easy, being responsible for them is another story. Mario diz portanto que o volume explode, a responsabilidade não migra, e abrir um PR ficou barato, mas detê-lo continua a sair caro.

Esta e a linha que se cola na matriz de hiring do lado do comprador. Quem carrega o pager por um sistema de produção em 2026 entende-a por instinto. A IA expande a superfície mais depressa do que a equipa pode crescer. A responsabilidade da equipa por essa superfície não cresce de todo. O resultado é compressão: os engineers sénior passam mais do día em revisão, ownership e recusa de output de IA, e menos a escrever código de raiz. A forma do trabalho está mais perto de um sénior reviewer numa loja de PRs de alta frequência do que de um sénior IC de há cinco anos.

Marko faz o mesmo ponto noutra linguagem: When something breaks at 2 a.m., it’s still engineers who make decisions and take responsibility. AI is powerful, but only as effective as the person using it. Marko acrescenta que quando algo parte às duas da manhã, são os engineers que decidem e assumem responsabilidade, e a IA é apenas tão eficaz quanto a pessoa que a utiliza.

Para os meus clientes de auditoria de segurança WordPress e assistência técnica WordPress, esta e a diferença operacional entre um contractor sénior e um intermediate aumentado por IA. O sénior é aquele cujo nome vai para o registo do runbook e cujo telefone toca quando o runbook falha. A IA não preenche essa função.

#Qual a diferença entre programador em forma de M e de T

O meio do artigo e a parte que os hiring managers menos vão reconhecer. Os quatro veteranos foram perguntados se o sucesso a longo prazo pende para o especialista profundo ou para o generalista largo, e três em quatro respondem que nenhum dos dois. Descrevem a forma de M: profundidade em vários domínios, acumulada por seguir os problemas em vez do plano de carreira.

Marina começa pelo T canónico e diz que deixou de descrever o seu trabalho: Earlier in my career, I believed that being a T-shaped developer was the ideal path and I assumed that trying to learn more than one thing deeply would only lead to superficial knowledge and that focusing on a single specialization was the safest way to grow. Over time, my view changed. Through real-world experience, I realized it’s possible to build strong, meaningful expertise in multiple áreas without losing depth. Marina descreve portanto a sua passagem do ideal em T para a perceção de que várias profundidades serias são possíveis sem perder profundidade.

Mario, com mais de vinte anos por Linux internals, redes, compiladores, contentores, orquestração e sistemas distribuídos, descreve o mesmo arco: So my view has evolved, I started as a T-shaped believer, and somewhere along the way I became something closer to M-shaped. Not by design, but by following the problems. Mario acrescenta que não foi por desígnio, mas por seguir os problemas.

Marko enuncia o princípio que liga tudo: What ties all of this together is problem-solving. Technologies change, but problems remain. Being able to learn continuously, adapt, and apply concepts from one domain to seemingly unrelated problems becomes incredibly valuable over the long term. Marko resume: as tecnologias mudam, os problemas permanecem, e o valor reside em aplicar conceitos de um domínio a problemas de outro.

Esta e a justificação técnica para o padrão de engineer composicional que marcas freelance polacas como a wppoland.com vendem. WordPress está ao lado de Astro, Next.js, Cloudflare Workers, Universal Commerce Protocol, prontidão NIS2 e auditorias de acessibilidade, não porque o engineer colecionou stacks como crachás, mas porque os problemas de produção atravessaram essas fronteiras. Um CV em forma de M é mais difícil de falsificar do que um CV em forma de T; a profundidade em cada bico é testável numa chamada de referência. O Portugal Talent Hub aponta o mesmo padrão: os perfis mais difíceis de preencher em 2025 não são os mais largos, mas aqueles que combinam duas ou três profundidades verificáveis em produção.

#Emprego para programadores júnior na era da IA

A linha mais dura do artigo é também de Mario, e não é otimista: Young developers are in a tight spot, suddenly expected to skip writing code by hand but still have the same depth of understanding. And I’m not sure you can skip that part. There’s something about writing code by hand, hitting a wall, debugging it yourself, and feeling the pain of it not working that builds intuition you can’t shortcut. Even if AI is faster and easier. Mario diz portanto que não se pode pular a escrita à mão sem perder a intuição que cresce precisamente dessa dor.

Para os júniores polacos, os números empíricos confirmam a tese de Mario. A No Fluff Jobs reportou que as ofertas de júnior caíram em 2025 para 5,3 por cento de todas as vagas, enquanto as ofertas sénior se mantiveram em 59,7 por cento. A medição da Just Join IT coloca as ofertas de júnior em 4,79 por cento e as sénior em 51,48 por cento. O pipeline que historicamente produzia engineers sénior (júnior escreve código à mão, bate na parede, aprende) está perturbado na camada de entrada, porque o júnior aumentado por IA produz output que parece sénior no ecrã e não é.

A recomendação de Marko no artigo e a mais pragmática: For junior developers, don’t skip the fundamentals. Expectations are higher than ever, but strong foundations are key for a sustainable career. The good news is that access to knowledge and AI tools is better than ever. Use AI to accelerate learning, not replace understanding. Marko resume que não há atalho à volta dos fundamentos, e a IA serve apenas para acelerar a aprendizagem, não para substituir a compreensão.

A receita tática de Mario: Write as much code by hand as you can. Use AI to review it, ask for other options, and have it challenge your approach, and then actually think through the answers. Mario dá a fórmula: escrever primeiro à mão, usar a IA depois como segundo par de olhos e pensar de facto sobre as respostas.

Se está a correr um programa de júnior ou mid em contexto polaco ou DACH em 2026, esta e a estrutura que se implementa, não a que se lê. A IA faz parte da toolchain, mas o exercício diário é primeiro código à mão e depois IA como segundo par de olhos.

Atualização, 24 de outubro de 2026. Um documento de trabalho do Stanford Digital Economy Lab, How Does AI Change Labor Demand? Evidence from 41 Countries, de Bharat Chandar e Bouke Klein Teeselink (21 de setembro de 2026, PDF), testa o mesmo padrão com muito mais dados: 1,25 mil milhões de anúncios de emprego e 154 milhões de registos de emprego entre janeiro de 2021 e março de 2026. Nas filiais estrangeiras de multinacionais que adotaram IA generativa, a quota de juniores na força de trabalho estava, em março de 2026, 1,9 pontos percentuais abaixo da de filiais comparáveis. A maior parte da diferença vem do crescimento acima do nível júnior: esse emprego subiu 6,7 por cento, enquanto o emprego júnior desceu 2,5 por cento, uma estimativa que os autores dizem não ser estatisticamente significativa. No estudo, júnior corresponde aos dois níveis de senioridade mais baixos nos dados da Revelio Labs, construídos sobretudo a partir de perfis do LinkedIn, e sénior começa logo no nível associate, pelo que não se trata de um cargo. A Polónia é um dos sete países, entre 31 estimados separadamente, onde a queda da quota de juniores é estatisticamente significativa. Em Portugal, 0,14 por cento dos anúncios da amostra estavam ligados a IA. Os próprios autores apontam os limites: o LinkedIn sobrerrepresenta gestores e profissionais qualificados, e o período cobre pouco mais de três anos após o ChatGPT. Para quem contrata, as portas de entrada na profissão estreitam-se, e o programador WordPress experiente que lê e corrige o código gerado por IA no seu projeto torna-se um recurso mais escasso. As perguntas da secção sobre contratação, mais abaixo, servem para o verificar.

#A IA vai tirar o emprego aos programadores na Polónia?

A 19 de outubro de 2026, a conta @dorszafranski partilhou no X uma publicação do subreddit polaco r/praca (citações do polaco, tradução própria). O autor apresenta-se como sénior numa grande empresa: “Há meio ano que não escrevo uma única linha de código à mão, a IA faz tudo por mim.” Ainda lê e corrige o que o modelo produz, por isso entrega mais devagar, enquanto “a maioria das pessoas já nem lê”. A empresa dele não contrata júniores há dois anos, dois programadores de nível intermédio e um sénior já saíram, e a equipa entrega mais funcionalidades do que nunca. Entre programadores, escreve, o tema principal são os planos para sair da informática.

No dia seguinte, @dorszafranski publicou a sua própria análise dos comentários. Analisou à mão 293 comentários na publicação e nas citações, deixando de fora os neutros. Dos 234 avaliados, 156 (67%) consideraram o cenário negro um exagero, e o comentário mais votado (630 gostos) chamou à publicação uma provocação para ganhar alcance. Numa pergunta à parte da conta @FinansowyUmysl sobre o plano para sair da informática, a resposta mais comum, segundo a contagem dele, foi “nenhum”. O paradoxo de Jevons também aparece: código mais barato pode aumentar a procura de software.

Os números de despedimentos explicam parte desta ansiedade. Connie Loizos escreveu no TechCrunch a 15 de junho de 2026 que a TrueUp contava cerca de 363 rondas de despedimentos em empresas tecnológicas desde o início do ano, afetando quase 150 000 pessoas, a um ritmo 44% mais rápido do que no ano anterior. As mesmas empresas apresentavam lucros e receitas recorde e indicavam a IA como razão oficial dos cortes. Ao mesmo tempo, crescia a desconfiança de que a IA fosse mais um pretexto conveniente do que a causa real. O exemplo que dá é a Block: Jack Dorsey começou por atribuir os cortes a ferramentas de IA e mais tarde admitiu que a empresa tinha contratado em excesso.

É um relato anónimo e uma amostra informal. Ainda assim, bate certo com o que os quatro séniores acima dizem: o código que ninguém leu continua a ter dono, a pessoa a quem telefonam quando algo falha. A um júnior aconselho praticar a leitura de código gerado por IA tantas vezes quanto escreve o seu, porque na empresa descrita foi precisamente ler e corrigir o que ficou com o sénior.

#Porque TDD e DDD contam mais com IA

A frase menos sexy e mais carregada economicamente que Denis diz na entrevista é aquela que os compradores deviam sublinhar. Lista trunk-based development, TDD, continuous delivery, modularidade, coesão e domain-driven design como mais valiosas em 2026 do que antes. Nada disto é novo. A maior parte existe desde o início dos anos 2000. A razão pela qual reaparecem no vocabulário de um sénior em 2026 é exatamente o choque da IA.

Trunk-based development conta mais porque o volume de PRs em equipas aumentadas por IA é mais alto; os branches longos morrem mais depressa. TDD conta mais porque o código gerado por IA passa o linter e falha a especificação; a especificação tem de existir em forma de teste antes de a IA arrancar. Continuous delivery conta mais porque o ritmo de mudança é mais alto; a superfície de deployment é o único lugar onde a latência se controla. Modularidade e coesão contam mais porque a IA gera código que atravessa fronteiras de módulo em silêncio; sem esqueleto arquitetural, essas travessias silenciosas viram a ball of mud que Mario descreveu. DDD conta mais porque as regras de negócio são a parte do sistema a que a IA tem menos acesso; o valor do sénior é manter o modelo.

Leia esta lista como sinal de compra. Um contractor sénior em 2026 que não consegue descrever o seu padrão de TDD, a sua cadência trunk-based e o seu mapa de contexto DDD não é um contractor sénior em 2026. É um intermediate com acesso a IA, o que é outro nível de preço.

#O trabalho de sénior ficou mais difícil com IA?

A ShiftMag é amistosa com as ferramentas de IA. Os quatro engineers usam todos. A polémica implícita, que o editor não puxou e que vou puxar, e a de que o trabalho de senior engineering em 2026 é assimetricamente mais difícil do que em 2022, enquanto o trabalho de junior engineering é assimetricamente mais fácil à superfície e assimetricamente mais difícil por baixo.

Assimetricamente mais difícil para séniores porque:

• o volume de revisão de PRs cresce mais depressa do que o headcount,
• as decisões arquiteturais têm de sobreviver a alternativas geradas por IA mais rápidas e mais autoconfiantes,
• a superfície de on-call cresce com o volume de código, não com o tamanho da equipa,
• a capacidade de recusar uma sugestão plausível de IA é hoje uma disciplina diária, não paga.

Assimetricamente mais fácil à superfície para júniores porque o output visível (código a funcionar, tickets fechados) chega mais depressa. Assimetricamente mais difícil por baixo porque o caminho de “produzi output” para “compreendo o sistema” já não passa por defeito por código escrito à mão. Os júniores têm de optar ativamente pelo caminho mais difícil. Poucos o farão, e é por isso que o prémio dos séniores se alarga.

Para os engineers freelance polacos, esta e a estrutura de mercado que paga. A mediana B2B sénior reportada pela No Fluff Jobs em 2024 estava em 24.360 PLN líquido por mês. O reset 2025-2026 preservou esse piso e amplificou a fatia sénior para perto de 60 por cento das vagas. O Portugal Talent Hub regista um padrão paralelo no mercado português: a procura mantém-se elevada em perfis com várias profundidades reais, e o prémio salarial desses perfis manteve-se ao longo de 2025. A convergência que a ShiftMag captou é como esses números se sentem por dentro.

#Como contratar um programador sénior em 2026

Se está a comprar engineering sénior em 2026, a convergência quádrupla na ShiftMag dá-lhe um filtro limpo:

1. Pergunte sobre sugestões de IA recusadas, semanalmente. Quem corre código de produção com assistência de IA recusa sugestões todas as semanas. Os pormenores filtram o teatro.
2. Leia pull request reviews que escreveu, não que recebeu. Autorar um PR é hoje barato com IA. Rever um é o sinal de sénior.
3. Percorra um incidente de produção do pager até ao post-mortem. A IA não preenche o on-call. A história contada sobre um incidente real é o sinal que sobrevive.
4. Compare o output com IA ligada e desligada para a mesma tarefa. O delta é o ganho real.
5. Pergunte pela forma de M. Dois ou três domínios profundos com sistemas nomeados. A forma de T era o ideal de 2018; em 2026 subvaloriza o engineer que se move pela stack quando o problema o exige.

Os quatro veteranos endossam implicitamente um funil de hiring em que os sinais de superfície (velocidade de digitação, fluência sintática, familiaridade com frameworks) foram todos achatados pela IA, e os sinais profundos (recusa, ownership, narrativa de on-call, memória arquitetural) ficaram compostos.

#O que é a engenharia composicional na era da IA

A frase única mais forte do texto da ShiftMag, e a que mais diretamente se mapeia na forma como esta marca vende, é o enquadramento de Marko: What ties all of this together is problem-solving. Technologies change, but problems remain. Marko resume portanto que as tecnologias mudam, os problemas permanecem, e essa e a âncora que conta ao longo dos anos.

O padrão do engineer composicional, em que um sénior se move entre WordPress, front-end headless, edge runtime, integração de IA e conformidade, não é um slogan de marketing. É a forma que o engineering em M assume quando a realidade da produção a impõe. A IA não inventou o padrão. Acelerou-o. Os quatro veteranos que a ShiftMag entrevistou descrevem a forma do trabalho de senior engineering em 2026 a partir de quatro ângulos diferentes, e a forma e a mesma.

Para uma colaboração freelance em 2026, a leitura prática é: pague pela recusa, pelo ownership e pela profundidade em vários domínios. A velocidade de digitação é hoje gratuita.

#Atualização, 2 de novembro de 2026: manifesto da Proton, harness de agentes e o Renaissance Developer

Seis meses após a publicação da entrevista na ShiftMag, a tese de que a engenharia sénior transita da sintaxe para a arquitetura de sistemas ganhou forte confirmação da liderança da indústria, a par dos seus bastidores mais desconfortáveis.

A 1 de novembro de 2026, a empresa suíça Proton publicou na íntegra o manifesto interno do seu CTO, Bart Butler: Programming is dead. Engineering is not. A perspetiva de Butler é direta: escrever código à mão deixou de ser a tarefa central do programador. O engenheiro lidera modelos e agentes como um gestor de equipa, eliminando atritos e desenhando salvaguardas de arquitetura. Quando um agente erra na autenticação ou gestão de sessões, a função humana não passa apenas por remendar a linha afetada. Consiste em aprimorar o sistema: registar regras de projeto no repositório, conceber testes TDD de regressão, delimitar permissões de API ou disponibilizar contexto conciso. Um engenheiro competente assegura que o mesmo erro não se repete.

Paralelamente, uma investigação da 404 Media revelou o outro lado na Proton: forte pressão da administração para acelerar a adoção de IA em detrimento de testes de segurança, com engenheiros a manifestarem preocupação pelo encurtamento dos prazos de testes de intrusão em sistemas encriptados. A Proton admitiu que a comunicação interna foi por vezes excessivamente ríspida. Para as empresas que contratam desenvolvimento tecnológico, a lição é claríssima: gerar código mais depressa sem dar aos seniores o poder de dizer “não” acumula dívida técnica e riscos operacionais graves à luz do RGPD e do Cyber Resilience Act.

Conclusões semelhantes chegaram de outras referências da indústria entre outubro e novembro:

1. Amazon e o Renaissance Developer: nas suas orientações internas atualizadas, a Amazon adverte expressamente contra o tokenmaxxing (queimar tokens e commits apenas para inflacionar métricas de produtividade). O valor reside na união entre ferramentas de IA, conhecimento aprofundado do domínio e juízo crítico do produto.
2. OpenAI e a exigência de harness: após 1500 pull requests gerados pelo Codex em cinco meses, a OpenAI abandonou a ideia de um único prompt gigantesco. O sucesso dependeu da construção de um harness rigoroso em torno do agente: mapa sintético do repositório, testes automatizados, análise de logs e inspeção no navegador.
3. Anthropic e a escala do monorepo Scion: perante mais de 30 mil alterações diárias no monorepo, o gargalo transferiu-se para o CI/CD. A tarefa mais valiosa dos seniores passou a ser recusar sugestões plausíveis do Claude que funcionavam localmente mas violavam limites do sistema.
4. PostgreSQL e o paradoxo de Robert Haas: a 30 de outubro, Haas alertou que o próximo grande lançamento da base de dados pode sofrer atrasos. Ferramentas LLM inundaram o projeto de notificações de bugs (o volume de commits subiu de 724 para 1169), pelo que a triagem e validação consumiram o tempo escasso dos programadores mais experientes.

A conclusão no fecho de 2026 é inequívoca: a sintaxe tornou-se barata. A arquitetura, o harness do agente, os testes de integridade e a autoridade para travar uma implementação prematura permanecem do lado humano.

Fontes citadas:

• Marko Crnjanski, “What 4 engineers with 10+ years of experience say about staying relevant in the AI era,” ShiftMag, 24 de abril de 2026.
• Bart Butler, “Programming is dead. Engineering is not,” Proton Blog / memorando interno, 1 de novembro de 2026.
• 404 Media, “Proton pushes AI coding despite internal security concerns,” finais de outubro / início de novembro de 2026.
• Robert Haas, “PostgreSQL commit patterns and bug detection in 2026,” 30 de outubro de 2026.
• No Fluff Jobs, “Rynek pracy IT 2025/2026.”
• Just Join IT, “Co z tym Eldorado? 2024/2025.”
• Portugal Talent Hub, panorama IT 2025.

Leitura relacionada neste site:

• Pilar de serviço Universal Commerce Protocol
• Desenvolvimento headless WordPress
• Auditoria de segurança WordPress
• Assistência técnica WordPress

Última atualização: 2026-11-02.

O que a IA deixa ao humano continua a incluir decidir que alegações são suficientemente seguras para GEO e LLMO numa página WordPress pública.