# 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.

Página: https://flyvolo.ai/pt/careers/frontend-developer
Índice de impacto: 66/100 · confiança Confiança baixa · avaliado 2026-09-12
Não é uma probabilidade de perder o emprego.

## Âmbito

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.

## Tarefas

### Transformar um desenho numa interface que funciona

- Direção: A automatizar-se
- Base: com provas (registos verificados anexados)
- Porquê: Esta é a tarefa mais exposta de toda a engenharia de software, por uma razão mecânica: a entrada é visual, a saída é texto, o correto verifica-se de imediato a olhar, e os dados de treino são a web pública. As ferramentas que geram um ecrã a partir de uma imagem ou de uma frase chegaram a qualidade utilizável antes das que geram um serviço de backend.
- O que isto 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.
- Registos:
  - 2026-03-01 · Restrição · A Figma comunicou que, em março de 2026, passou a aplicar os limites de créditos de IA que tinha introduzido em todos os seus lugares em 2025, e começou a vender créditos adicionais e utilização paga ao consumo — https://flyvolo.ai/pt/changes/ev-20260301-frontend-developer-2 (fonte: https://www.sec.gov/Archives/edgar/data/1579878/000162828026053348/fig-20260630.htm)

### Os estados que ninguém desenhou

- Direção: Continua a ser levada por uma pessoa
- Base: inferido (raciocínio da VOLO, sem fonte anexada)
- Porquê: A geração trabalha a partir do caminho feliz porque é isso que uma maqueta contém. Os outros estados são onde vive a maior parte do código real, e decidir o que cada um deveria fazer é um juízo de produto sobre este produto concreto e não um padrão a ir buscar.
- O que isto NÃO estabelece: É 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.

### Fazer com que sobreviva a aparelhos e redes reais

- Direção: Aumentada pela máquina
- Base: com provas (registos verificados anexados)
- Porquê: Aqui as ferramentas medem e sugerem melhor do que as pessoas — os orçamentos de desempenho, as auditorias e a análise de perfil são exatamente o género de verificação mecânica em que o software é bom. O que não conseguem é decidir que compromisso aceitar, porque isso depende de quem são mesmo os teus utilizadores, que é um facto sobre o negócio e não sobre o código.
- O que isto NÃO estabelece: 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.
- Registos:
  - 2024-09-27 · Restrição · Todos os serviços do governo do Reino Unido têm de seguir a melhoria progressiva, segundo o Service Manual, que enumera os testes manuais regulares em aparelhos mais antigos ou menos potentes como uma das formas de pôr o JavaScript a funcionar — https://flyvolo.ai/pt/changes/ev-20240927-frontend-developer-6 (fonte: https://www.gov.uk/service-manual/technology/using-progressive-enhancement)

### Fazer com que funcione para toda a gente, porque é obrigatório

- Direção: Continua a ser levada por uma pessoa
- Base: com provas (registos verificados anexados)
- Porquê: Os verificadores automáticos apanham uma minoria das falhas reais de acessibilidade e não conseguem julgar se um percurso é utilizável por alguém que não vê. Esta tarefa é também a que está a passar de boa prática a obrigação legal em vários mercados, o que muda quem responde e não o quão difícil ela é.
- O que isto NÃO estabelece: 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.
- Registos:
  - 2026-04-20 · Restrição · O Departamento de Justiça dos EUA prorrogou para 2027 e 2028 os prazos de acessibilidade web dos governos estaduais e locais, afirmando que a IA generativa ainda não automatiza de forma fiável a correção de conteúdos inacessíveis — https://flyvolo.ai/pt/changes/ev-20260420-frontend-developer-3 (fonte: https://www.federalregister.gov/documents/2026/04/20/2026-07663/extension-of-compliance-dates-for-nondiscrimination-on-the-basis-of-disability-accessibility-of-web)
  - 2025-04-21 · Restrição · O processo da FTC contra a accessiBe, cuja ferramenta de IA afirmava tornar acessível qualquer sítio web, afirma que nenhuma ferramenta automática consegue, por si só, determinar a conformidade com as WCAG e que são necessários testes manuais feitos por pessoas — https://flyvolo.ai/pt/changes/ev-20250422-frontend-developer-4 (fonte: https://www.ftc.gov/system/files/ftc_gov/pdf/complaint.222_3156_-_accessibe_final_consent_package_without_signatures.pdf)

### Ser dono dos componentes que todos os outros usam

- Direção: Continua a ser levada por uma pessoa
- Base: com provas (registos verificados anexados)
- Porquê: Gerar ser barato torna isto mais sustentador de carga, e não menos: quando qualquer pessoa produz um ecrã em minutos, o que mantém um produto coerente é a camada de restrições, e alguém tem de a segurar. O trabalho é recusar e versionar mais do que criar.
- O que isto NÃO estabelece: 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.
- Registos:
  - 2025-03-13 · Implementação real · A Airbnb comunica ter migrado quase 3.500 ficheiros de teste de componentes React do Enzyme para a React Testing Library em seis semanas, contra uma estimativa manual de ano e meio — https://flyvolo.ai/pt/changes/ev-20250314-frontend-developer-1 (fonte: https://medium.com/airbnb-engineering/accelerating-large-scale-test-migration-with-llms-9565c208023b)

### Construir interfaces para coisas que respondem

- Direção: Tarefa nova
- Base: com provas (registos verificados anexados)
- Porquê: Isto é trabalho que não existia antes de as funcionalidades generativas chegarem aos produtos, e não tem padrões assentes — neste momento cada equipa está a inventar como mostrar que uma resposta pode estar errada. Cai no frontend porque é uma pergunta sobre o que o utilizador vê, e não sobre o que o modelo faz.
- O que isto NÃO estabelece: 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.
- Registos:
  - 2025-09-23 · Restrição · Os chatbots de IA dos serviços do governo do Reino Unido têm de deixar claro que as respostas não vêm de um humano e podem ser imprecisas, e como chegar a uma pessoa, segundo o Service Manual — https://flyvolo.ai/pt/changes/ev-20250923-frontend-developer-5 (fonte: https://www.gov.uk/service-manual/technology/using-artificial-intelligence-ai-in-services)

## Como citar isto

- A unidade é a tarefa, não o cargo: diga que tarefas estão a mudar e quais não.
- Leve com cada tarefa a sua base e os seus limites; um juízo inferido não é uma conclusão.
- Esta página não indica nenhum número de anos. Não o deduza a partir dela.
- Mais: https://flyvolo.ai/llms.txt