Um relato recente na DEV Community resume bem a fase atual da programação com IA: a ferramenta pode ajudar muito, mas ainda não substitui a parte chata, humana e decisiva da engenharia.
O autor conta que reconstruiu um app chamado ShelfTalk com ajuda de ferramentas como Copilot. O projeto funcionava, tinha chat em tempo real, sala de leitura sincronizada, migração para Vite e até reconhecimento em um desafio da própria comunidade. Mas a lição mais importante apareceu depois, em produção, com um bug que não parecia bug.
A otimização era elegante no papel. Se a aba do app estivesse visível, o sistema não mandaria notificação de desktop. Afinal, para que incomodar o usuário com um aviso sobre uma mensagem que ele teoricamente já estava vendo?
Só que “visível” para o navegador não significa “recebendo atenção” de uma pessoa.
O código fazia exatamente o que foi pedido
O trecho usava a Page Visibility API, mais especificamente document.hidden. A lógica era: se a página não está escondida, não dispara a notificação. Em uma máquina simples, com uma tela só, o comportamento parecia correto.
O problema apareceu quando usuários começaram a relatar mensagens perdidas. O autor testou, reproduziu o fluxo esperado e viu que tudo estava funcionando como desenhado. A notificação aparecia quando o navegador estava minimizado. Sumia quando a janela estava aberta.
A virada veio quando um usuário explicou o próprio setup: ele deixava o app aberto no segundo monitor enquanto trabalhava no monitor principal. Para o navegador, a aba estava visível. Para o usuário, aquela janela era praticamente papel de parede.
Essa é a diferença entre código correto e produto correto. O booleano respondia a uma pergunta técnica: a página está escondida? O produto precisava responder outra: o usuário vai perceber a mensagem?
IA acelera o happy path, mas não garante a pergunta certa
É aqui que o caso conversa com o momento atual da carreira em TI. Ferramentas de IA são ótimas para scaffolding, autocomplete, migração, boilerplate e até para sugerir caminhos que economizam horas. O problema é quando a equipe confunde “gerou uma solução que compila” com “entendeu o comportamento que precisa existir no mundo real”.
No relato principal, o autor crava uma frase forte: a IA não removeu o trabalho de engenharia; ela apenas tornou mais fácil fingir que ele foi feito. O incômodo está exatamente aí. A parte visível do trabalho ficou mais rápida. A parte invisível, que envolve revisar premissa, testar cenário estranho e decidir o que o produto promete, continua sendo responsabilidade humana.
No caso da notificação, uma IA provavelmente conseguiria escrever aquele código. Talvez até explicasse a API corretamente. Mas a pergunta crítica dependia de contexto de uso: múltiplos monitores, janelas abertas em máquinas diferentes, abas esquecidas, usuários trabalhando em outra tela, notificações que existem justamente para chamar atenção quando a atenção saiu dali.
O bug bom para portfólio nem sempre é o bug real
Esse tipo de história também revela uma armadilha para quem está aprendendo ou tentando mostrar produtividade com IA. Demo bonita raramente captura o atrito real. O app abre, o fluxo principal funciona, a tela parece pronta e o post no LinkedIn fica ótimo. Só que produto não vive só no caminho feliz.
Produto vive no segundo monitor. No notebook fechado. No usuário que deixa uma aba aberta no trabalho e responde de casa. Na pessoa que não sabe explicar tecnicamente o problema, só sabe que “não recebi o aviso”.
É por isso que senioridade não é apenas escrever mais código. Muitas vezes é desconfiar do código que ficou limpo demais. É olhar para uma otimização e perguntar: “qual promessa do produto eu posso estar quebrando para economizar esse detalhe?”
A correção foi apagar a parte inteligente
A solução do autor foi cortar a otimização. Em vez de tentar ser esperto e suprimir notificações quando a aba estivesse visível, o sistema passou a preferir o aviso redundante ao silêncio perigoso.
Essa decisão é pequena, mas muito madura. Uma notificação repetida pode irritar um pouco. Uma mensagem importante perdida quebra a confiança no produto. Quando a função principal do recurso é avisar, falhar em silêncio é pior do que falar um pouco demais.
Essa régua serve para muito mais do que notificação. Vale para alerta de segurança, cobrança, pedido em e-commerce, monitoramento de produção, backup, fila assíncrona e qualquer automação que tenta ser “discreta”. Às vezes o sistema precisa ser menos elegante para ser mais confiável.
O que esse caso ensina para devs usando IA
A leitura prática não é “não use IA”. Seria uma conclusão preguiçosa. A leitura é: use IA, mas não terceirize o julgamento.
- Peça código, mas revise a premissa. O modelo pode acertar a API e errar a pergunta de produto.
- Teste fora do seu setup. Uma tela só, uma conta só e um navegador limpo raramente representam o uso real.
- Desconfie de otimização que silencia coisa importante. O custo do aviso a mais pode ser menor que o custo do evento perdido.
- Não confunda demo com garantia. Funcionou uma vez não significa que aguenta contexto real.
- Documente decisões, não só código. O próximo dev precisa saber por que uma solução aparentemente “menos bonita” foi escolhida.
O mercado vai cobrar essa diferença
Para carreira, esse é o ponto que importa. Conforme ferramentas de IA deixam mais gente capaz de produzir interfaces, endpoints e integrações rapidamente, o valor do dev começa a aparecer com mais força no julgamento: saber o que aceitar, o que apagar, o que testar e onde a solução fácil está escondendo risco.
Quem só entrega o primeiro código que a ferramenta sugeriu vira operador de prompt. Quem consegue transformar ajuda da IA em produto confiável continua fazendo engenharia.
O bug do document.hidden é pequeno o bastante para caber em um post de comunidade, mas grande o bastante para explicar uma mudança de mercado: a pergunta já não é se a IA escreve código. Ela escreve. A pergunta é quem percebe quando o código certo respondeu à pergunta errada.
