LO
Avisa-me quando chegar um registo verificado a esta profissão → · Marque quais destas tarefas são suas (VOLO Pro, gratuito) → · Para uma equipa ou um curso de finalistas →
Programador frontend
Constrói a superfície em que as pessoas mexem mesmo — e fica com as partes a que um ecrã gerado não sobrevive: aparelhos reais, redes reais, e a exigência legal de funcionar para toda a gente.
Pega num ecrã do teu produto e lista todos os estados em que ele pode estar. Depois confirma quantos deles existem mesmo no código.
Isto não é uma probabilidade de perder o emprego. Combina que parte da carga de tarefas do posto está exposta à automatização com até onde a adoção chegou de facto: serve para comparar profissões sobre uma base constante, e para mais nada.
Escrito para engenheiros que constroem interfaces web e de aplicação. Corta por camada e não por senioridade — as páginas de software júnior e experiente cortam ao contrário, e um engenheiro de frontend sénior está nas duas. O design em si é uma profissão à parte; o móvel nativo e os jogos divergem.
O que está mesmo a mudar#
A unidade de análise é a tarefa, não o nome do posto. Um posto não é substituído: é a mistura de tarefas dele que se move.
Cada quadrado é uma tarefa. O tamanho é o peso que tem no trabalho; a cor, para onde a tarefa está a ir. Clique num quadrado para ver o que esse juízo não estabelece.
Um ecrã que aparece não é um ecrã que entra em produção. Nada diz sobre se o resultado é mantível, se encaixa num sistema de design existente, ou como se comporta nos estados que ninguém desenhou — vazio, a carregar, erro, meia lista.
É um juízo sobre onde está o trabalho, não uma medição dele. As equipas não contam que parte do seu código frontend é tratamento de casos-limite, pelo que não há número com que confrontar isto, e o equilíbrio varia enormemente entre uma página de marketing e um ecrã de negociação.
Uma norma de um governo exige estes testes para os seus próprios serviços; nada aqui diz quantas horas isto leva noutros lados nem se as equipas sequer o fazem — grande parte do trabalho de frontend que é publicado nunca recebe esta atenção, e as ferramentas existirem não significa que tenham sido corridas.
Uma ação de um regulador enumerou as barreiras que ficaram em sítios web que confiavam numa sobreposição automática, sem nomear os sítios; o que resolveria mais a questão é uma ação de fiscalização que nomeie uma interface concreta e o que nela estava errado. Os requisitos variam consoante o mercado e consoante o produto se dirigir ou não ao consumidor.
Que isto seja um posto ou uma tarefa acrescentada depende inteiramente da dimensão da equipa, e quantas equipas lhe atribuem alguém de forma deliberada é coisa que ninguém conta.
Aparecer trabalho novo não é o mesmo que efetivos novos: isto está a ser absorvido pelos lugares existentes, e nada aqui diz que alguém tenha sido contratado para o fazer.
É este o teu trabalho? Di-lo e esta página estreita-se à tua parte dele.
O nome de um posto é um pacote de tarefas compradas em conjunto, e não há duas pessoas com o mesmo pacote. Não é enviado nada para lado nenhum: fica neste navegador.
Mudanças recentes#
Uma norma federal dos EUA que vincula os governos estaduais e locais ao abrigo do Título II da Americans with Disabilities Act. A norma de 2024 exige que os seus conteúdos web e aplicações móveis cumpram as WCAG 2.1 AA; esta norma final provisória, em vigor desde 20 de abril de 2026, prorroga o prazo de cumprimento para 26 de abril de 2027 no caso das entidades com 50.000 ou mais habitantes e para 26 de abril de 2028 no caso das mais pequenas e dos distritos especiais. Na sua fundamentação, o Departamento diz que tecnologia avançada como a IA generativa ainda não automatiza de forma fiável a correção de conteúdos inacessíveis em larga escala, e que quanto menos as entidades públicas puderem contar com a tecnologia para tornar os conteúdos acessíveis, mais terão de contar, em vez disso, com trabalho manual. Isso é a fundamentação do Departamento, não uma disposição vinculativa, e diz respeito a corrigir conteúdos existentes e não a construir interfaces novas; a norma vincula governos, não empresas privadas.
Uma falha, um recuo, uma regulação ou um custo estão a travar a adoção. Pode baixar uma avaliação ou alargar a sua incerteza.
O documento estabelece a medição, não o seu efeito. A Figma declara que introduziu créditos de IA em todos os lugares durante 2025 e que passou a aplicar os limites em março de 2026, vendendo acréscimos mensais ou utilização paga ao consumo acima deles; o documento indica o mês, não o dia. Não apresenta qualquer número de utilização do Figma Make ou do Dev Mode. Diz apenas que, depois de os limites passarem a ser aplicados, registou mais pedidos de suporte, algum descontentamento público e uma utilização reduzida por parte de certos clientes, sem medir quanto. A Figma vende esses lugares, pelo que tem interesse na forma como uma alteração de preços é apresentada — mas o facto aqui registado, o de que gerar uma interface a partir de um design passou a consumir créditos medidos em vez de estar incluído no lugar, consta de um documento em que exagerar acarreta responsabilidade. Nada diz sobre ferramentas de outros fornecedores, nem sobre canais de produção internos.
Uma falha, um recuo, uma regulação ou um custo estão a travar a adoção. Pode baixar uma avaliação ou alargar a sua incerteza.
A norma do governo central do Reino Unido para construir serviços digitais públicos. Se um serviço usa IA, tem de deixar claro aos utilizadores de que forma isso pode afetar os seus dados e o resultado ou a informação que recebem; se usa um chatbot com IA, tem de garantir que os utilizadores percebem que as respostas não vêm de um ser humano e podem não ser exatas, e que sabem como contactar um ser humano. A página diz também que os serviços devem estar preparados para deixar de usar IA se for preciso. Vincula as equipas de serviço do governo central do Reino Unido, não empresas privadas, e fixa o que a interface tem de comunicar, não como uma equipa a constrói.
Uma falha, um recuo, uma regulação ou um custo estão a travar a adoção. Pode baixar uma avaliação ou alargar a sua incerteza.
A queixa do regulador norte-americano da defesa do consumidor contra uma empresa que vendia um widget com IA apresentado como capaz de pôr qualquer sítio web em conformidade com as Web Content Accessibility Guidelines, resolvida por uma decisão final que impõe um pagamento de 1 milhão de dólares e proíbe afirmações desse tipo sem provas. A queixa afirma que, segundo especialistas em acessibilidade, nenhuma ferramenta de testes automáticos consegue, por si só, determinar se um sítio web cumpre as normas de acessibilidade e que são necessários testes manuais feitos por pessoas, e enumera barreiras que continuavam nos sítios que usavam o produto: indicadores de foco em falta, armadilhas de teclado em formulários e menus, texto alternativo em falta ou impreciso, cabeçalhos incorretos. É um processo de publicidade enganosa resolvido por acordo, a frase dos especialistas cita especialistas externos, e os sítios afetados não são nomeados.
Uma falha, um recuo, uma regulação ou um custo estão a travar a adoção. Pode baixar uma avaliação ou alargar a sua incerteza.
O código de uma empresa, publicado por essa empresa, com a estimativa da migração manual (ano e meio de tempo de engenharia) dada pela mesma empresa e não verificável de fora. O que torna o resultado reproduzível é o mecanismo, que a publicação descreve por inteiro: a migração é uma máquina de estados em que cada passo tem um árbitro automático — o jest, o eslint e o tsc dizem passa ou falha — por isso o modelo podia voltar a tentar sem ninguém a ver, e a primeira passagem em massa resolveu 75% dos ficheiros em quatro horas. A cauda que sobrou é o número mais útil: ao fim de quatro dias de afinação, 97%; muitos dos ficheiros da cauda tinham sido tentados entre 50 e 100 vezes, e os últimos 3% foram terminados à mão. A publicação é também explícita em que o fator principal foi selecionar os ficheiros relacionados certos para pôr na instrução — que cresceu para entre 40 000 e 100 000 tokens puxando até 50 ficheiros — e não a redação da instrução. Não comunica qualquer mudança de efetivos, de contratação ou de lugares, nem o afirma.
Uma empresa pô-lo em produção. Pode mover a linha de base, ponderado pela escala e por quanto esse contexto se parece com o teu.
A norma do governo central do Reino Unido para construir serviços digitais públicos. Todos os serviços do governo têm de seguir a melhoria progressiva — funcionar primeiro com HTML e só depois acrescentar CSS e JavaScript — mesmo que parte do serviço precise de JavaScript. Para pôr o JavaScript a funcionar em todos os navegadores, a página enumera a deteção de funcionalidades, os polyfills e a transpilação, o uso de testes automáticos ou de linters, e a realização de testes manuais regulares, incluindo testes com aparelhos mais antigos ou menos potentes. Vincula as equipas de serviço do governo central do Reino Unido; é uma norma sobre como o trabalho tem de ser feito, não uma medição de quanto dele está automatizado.
Uma falha, um recuo, uma regulação ou um custo estão a travar a adoção. Pode baixar uma avaliação ou alargar a sua incerteza.
O que isto significa para ti#
A tarefa para que antes terias sido contratado primeiro — transformar um desenho num ecrã — é a mais exposta aqui. Isso vale a pena saber antes de passares um ano a ficar rápido nela. As partes que se aguentam são os estados que ninguém desenhou e a exigência de funcionar para toda a gente, e nenhuma delas se aprende a construir páginas de portefólio.
A tua alavanca passou de produzir ecrãs para os restringir: o sistema de design, os estados, o orçamento de desempenho, a obrigação de acessibilidade. É trabalho menos visível e mais difícil de mostrar num portefólio, o que é um problema real da próxima vez que mudares de emprego — começa a guardar um registo do que recusaste e porquê.
As tuas opções#
Quatro direções, cada uma com as suas restrições reais e com uma coisa que podes testar esta semana. Continuar como estás é uma opção legítima; só tem de ser uma opção escolhida.
Ser dono da camada de restrições
Quando os ecrãs ficam baratos, o que escasseia é a pessoa que mantém um produto coerente — a biblioteca de componentes, os estados, o orçamento de desempenho.
É trabalho pouco visível que facilmente se dá por garantido, e precisa de uma equipa grande que chegue para a coerência contar.
Pega num ecrã do teu produto e lista todos os estados em que ele pode estar. Depois confirma quantos deles existem mesmo no código.
Seres quem consegue provar que é acessível
Isto está a passar de boa prática a obrigação em vários mercados, e uma obrigação precisa de uma pessoa com nome que consiga demonstrar o cumprimento em vez de o afirmar.
Exige aprender a testar com tecnologia de apoio em vez de com um verificador, coisa que a maioria dos engenheiros nunca fez.
Liga um leitor de ecrã e completa um percurso do teu próprio produto sem olhar para o ecrã. Anota onde encalhaste.
Aproximares-te da decisão de produto
Os engenheiros de frontend veem o que as pessoas fazem mesmo mais diretamente do que quase toda a gente, e essa observação é a matéria-prima do trabalho de produto.
Exige abdicar de ser quem melhor conhece o código, e aprender a discutir com números em vez de com gosto.
Encontra uma funcionalidade que tenhas construído e que ninguém usa, e vai descobrir porquê. A resposta quase nunca é a que a equipa assumia.
Perguntas frequentes#
Nenhum número aqui seria honesto, e a pergunta faz-se melhor tarefa a tarefa. Produzir um ecrã a partir de um desenho é já em grande medida feito por máquina; decidir o que o ecrã faz quando faltam os dados não é, nem responder por ele funcionar para alguém que usa um leitor de ecrã. Um sinal que consegues verificar: quanto do teu último mês foi escrever marcação contra decidir comportamento. Se foi sobretudo o primeiro, a exposição é real e o passo é na direção do segundo.
Na sua tarefa mais visível, é, e a razão é mecânica e não um juízo sobre dificuldade: a entrada é visual, a saída é texto, o correto verifica-se a olhar, e os dados de treino são a web pública. Mas a maior parte de um código de frontend real não é essa tarefa — são os estados que ninguém desenhou, os aparelhos em que ninguém testou, e as restrições que mantêm coerente um produto que cresce. Estar exposto na metade visível não é estar exposto no trabalho.
A amplitude não é automaticamente proteção, e é esse o enquadramento que vale a pena largar. Duas exposições superficiais são mais fáceis de substituir do que uma profunda; o que protege é ser a pessoa em quem se confia para julgar, e o critério é específico de um domínio. Se atravessares, atravessa por uma razão — os estados e o modelo de dados estão mesmo ligados, e perceber os dois torna-te melhor na fronteira, que é onde vive a maioria dos erros.
Continua a ser pedido, e é um sinal cada vez mais fraco pela mesma razão que a primeira tarefa desta página: quem o analisa já sabe quanto custa produzir um ecrã bonito. O que não enfraqueceu é a evidência de critério — um componente que retiraste e porquê, um estado que trataste e que ninguém especificou, um orçamento de desempenho que seguraste sob pressão. Isso é mais difícil de juntar e muito mais difícil de gerar.
A estudar para isto?
Estes cursos levam até aqui. As páginas deles desdobram quais das suas competências se transferem e o que costuma faltar a quem se licencia.
Em que assentam estes juízos#
Dos 6 juízos de tarefa desta página, 5 apoiam-se num evento verificado e 1 são inferência da plataforma, cada um etiquetado onde aparece. Por detrás há 2 dimensões tecnológicas, uma trajectória reconstruída desde que os modelos de linguagem chegaram ao público e 6 eventos verificados.
Ver que tecnologias, como chegou aqui e o método →
Onde se situa na classificação oficial: competências, conhecimentos e profissões afins →
Outros cargos na mesma função#
Uma empresa divide o seu trabalho em funções antes de o dividir em cargos. Estes estão em Tecnologia e dados ao lado deste — um facto sobre organigramas, não um juízo de que sejam parecidos ou de que estejam a mudar na mesma direcção.
Programador de software júnior · Engenheiro de software experiente · Programador backend · Engenheiro de dados · Engenheiro de aprendizagem automática · Investigador de IA · Testador de software / engenheiro de QA · Analista de dados · Cientista de dados · Estatístico · Economista · Analista de negócio · Responsável de sistemas de negócio · Técnico de suporte informático / helpdesk · Analista de segurança (SOC) · Engenheiro de DevOps / engenheiro de plataforma / SRE · Engenheiro de redes · Redator técnico / engenheiro de documentação · Gestor de candidaturas a financiamento