Durante muito tempo, nem sequer tinha a certeza de que este site precisava de um blog.
Já passo a maior parte do meu tempo de trabalho a resolver problemas. Alguns são tarefas normais de frontend ou backend. Outros tornam-se muito mais específicos: codificação de imagens, comportamento de browsers, experiências de SEO, falhas de infraestrutura, desenvolvimento assistido por IA, processamento de media ou algum problema estranho em produção que começa com uma pergunta simples e acaba por exigir vários dias de investigação.
Depois disso, escrever mais alguns milhares de palavras pode parecer desnecessário.
Quem vai ler?
O que ganho com isso?
Porque não resolver simplesmente o problema e seguir em frente?
Acabei por encontrar uma resposta que para mim é suficiente: uma parte deste trabalho custa demasiado para ser simplesmente deitada fora.
Um problema difícil pode conter um artigo inteiro antes de eu perceber
Os meus artigos normalmente não começam com o pensamento: “Esta semana tenho de escrever um post.”
Começam com um problema.
Às vezes vem do meu trabalho, outras vezes de um dos meus próprios projetos. E às vezes alguma coisa que não compreendo desperta o meu interesse e continuo a aprofundá-la até a entender muito melhor.
O processamento de imagens levou-me muitas vezes por estes caminhos.
No início, a tarefa pode soar quase ridiculamente simples:
Pega nestas imagens e torna-as mais pequenas.
Pode pedir-se um script a um modelo de IA e receber algo quase imediatamente.
Isso não significa que exista uma boa pipeline de processamento de imagens.
A primeira versão pode ignorar diferenças entre JPEG, PNG, WebP e conteúdo animado. Pode usar o mesmo valor de quality para tudo, fazer upscale sem necessidade, lidar mal com transparência, preservar metadata que queríamos remover ou destruir metadata que queríamos manter. Pode otimizar apenas o tamanho do ficheiro sem medir o dano visual. Pode funcionar perfeitamente em dez ficheiros de teste e tornar-se um erro muito caro quando aplicada numa escala muito maior.
Um script que termina sem erros não é o mesmo que um sistema em que confio.
Muitos dos meus artigos nascem precisamente dessa diferença.
O meu workflow com IA é muito mais lento do que “perguntar a resposta ao ChatGPT”
Uso bastante uma conta paga do ChatGPT quando trabalho em problemas deste tipo.
Uma única conversa pode durar dias ou semanas. Faço perguntas, testo sugestões, devolvo resultados, questiono pressupostos, inspeciono código, encontro outro edge case, altero a implementação, volto a executar, comparo o resultado e repito.
Em investigações particularmente profundas, cheguei a acumular mais de 100 horas de trabalho em torno do mesmo problema mais amplo.
Isso não significa que passe 100 horas à espera de que um modelo de IA descubra magicamente a resposta.
O processo é iterativo.
Normalmente parece-se mais com isto:
- Descrevo o problema.
- O modelo propõe uma solução inicial.
- Executo-a com dados reais.
- Alguma coisa é fraca, ineficiente ou simplesmente errada.
- Levo a evidência de volta à conversa.
- Mudamos a abordagem.
- Volto a testar.
- Surge outro edge case.
- Repetimos.
Esse ciclo pode acontecer muitas vezes.
O resultado útil raramente é o primeiro script. É o conjunto acumulado de falhas, medições, correções e decisões em torno dele.
A IA tornou barato gerar um ponto de partida. Não tornou barata a verificação
Esta é uma das razões por que considero demasiado simplista a discussão habitual sobre conteúdo técnico escrito com IA.
Sim, um modelo de IA consegue produzir muito rapidamente um tutorial plausível.
Também consegue produzir código que parece perfeitamente razoável e está errado exatamente nas situações que interessam.
Em problemas técnicos muito específicos, raramente quero a primeira resposta plausível. Quero saber o que acontece quando a executo de verdade.
Se estou a construir uma pipeline de imagens, quero inspecionar tamanhos de saída e qualidade visual. Quero saber o que acontece com diferentes formatos de origem. Quero testar dimensões pouco comuns, alpha, animações e inputs corrompidos. Quero compreender os pressupostos feitos pela implementação.
Se o script acabar por tocar numa coleção enorme, este trabalho torna-se ainda mais importante.
Dez milhões de imagens é deliberadamente um exemplo extremo, não uma afirmação sobre o tamanho de um dataset específico meu. Mas ilustra bem o problema: um pequeno erro sistemático multiplicado dez milhões de vezes deixa de ser pequeno.
O custo de gerar código caiu drasticamente.
O custo de determinar se esse código merece ser executado em escala não caiu da mesma forma.
O chat é material de investigação, não o artigo final
Depois de uma investigação longa, o histórico da conversa pode conter uma quantidade absurda de informação.
Pode conter:
- abordagens que falharam;
- código que acabou por ser substituído;
- resultados úteis de benchmarks;
- logs;
- mal-entendidos;
- correções;
- explicações de comportamentos obscuros;
- comparações entre alternativas;
- edge cases em que inicialmente não tinha pensado;
- e as regras finais em que acabei por confiar.
Deixar tudo isso fechado numa conversa privada parece-me desperdício.
Por isso retiro as partes úteis e transformo-as num artigo.
O artigo não é uma transcrição da conversa. A maior parte da conversa nunca deveria tornar-se artigo.
Um artigo técnico útil precisa de mais uma passagem: remover becos sem saída que não ensinam nada, preservar aqueles que explicam algo importante, verificar afirmações, reconstruir a cronologia, distinguir observação de explicação e transformar o resultado em algo que outro developer possa realmente usar.
Esta etapa editorial importa.
A IA pode participar nela, mas a evidência continua a vir do trabalho real.
O processamento de imagens ensinou-me quão profundo pode tornar-se um problema “simples”
A otimização de imagens é provavelmente o exemplo mais claro do meu próprio trabalho.
Passei tempo suficiente neste tema para ver aquilo que inicialmente parecia uma coleção de configurações de encoder transformar-se gradualmente num problema de sistemas muito maior.
As perguntas mudam rapidamente.
Com que formato de origem estou a trabalhar?
É animado?
As dimensões devem mudar?
Como escolho a qualidade?
Que métrica deve decidir se a perda de qualidade é aceitável?
Um único quality threshold funciona com imagens completamente diferentes?
Como evito upscaling?
Que metadata deve sobreviver?
O que acontece à transparência?
Como deve o output ser validado?
Um ficheiro menor justifica realmente o custo adicional de encoding?
O que acontece quando a população de inputs muda?
É por isso que sou cético em relação a scripts de cinco linhas de “otimização definitiva de imagens”.
Eles conseguem certamente processar uma imagem.
Isso é diferente de construir uma pipeline cujos compromissos compreendemos.
Para os meus workloads atuais, ricos em imagens, AVIF costuma ser o primeiro formato que considero. É uma regra baseada no tipo de projetos em que trabalho, não uma afirmação de que todos os sites do mundo devam apagar amanhã todos os formatos mais antigos. Requisitos de compatibilidade, material de origem, latência, custo do encoder e arquitetura de delivery podem mudar a resposta.
O interessante não é declarar um formato vencedor.
É compreender suficientemente bem o workload para tomar a decisão de forma consciente.
Quero aprofundar da mesma forma o processamento de vídeo. Ainda não cheguei lá. É parte do que torna estes temas interessantes: sempre que penso ter chegado ao fundo de um problema, aparece outra camada.
Depois um site japonês encontrou o blog
Não esperava qualquer retorno específico ao publicar estes artigos.
Este blog não me dá um retorno financeiro significativo. Faço-o porque gosto do processo e porque prefiro preservar trabalho útil em vez de o deixar desaparecer em chats antigos e no histórico do terminal.
Depois aconteceu algo que realmente não esperava.
A 17 de setembro de 2026, o site japonês Levtech Freelance publicou uma seleção cujo título poderia ser traduzido aproximadamente como “Blogs recomendados para engenheiros que querem melhorar as suas competências”.
O artigo da Levtech Freelance incluiu o JSVar ao lado de vários outros blogs de engenharia.
A Levtech faz parte de um grande ecossistema japonês de carreiras em IT, e a Levtech Freelance concentra-se no apoio e na ligação de engenheiros de IT freelance a oportunidades. Para mim, a parte interessante não era simplesmente conseguir um backlink. Era perceber que partes do meu trabalho uma equipa editorial externa considerava interessantes o suficiente para descrever.
A secção sobre o JSVar destacou especialmente três artigos.
Um explicava porque considerei Codex e TypeScript uma boa combinação em development de produção, sobretudo porque os types e o feedback do compilador do TypeScript podem revelar problemas no código gerado.
Outro falava da tradução do blog para 20 idiomas com ChatGPT e de ver visitantes vindos de search de diferentes países chegarem diretamente às páginas localizadas.
O terceiro era a minha experiência de publicar 10.000 páginas SEO geradas por IA, que acabou por se transformar mais numa história de fracasso do que de crescimento fácil.
A escolha divertiu-me porque são três artigos muito diferentes, mas partilham o mesmo padrão.
Todos se baseiam em algo que realmente fiz.
Não sei exatamente como a Levtech me encontrou
Há aqui uma história muito tentadora.
Não falo japonês.
O meu site tem uma versão japonesa.
Uma publicação japonesa de engenharia encontrou o site.
Logo, traduzir o blog para japonês fez com que a Levtech o descobrisse.
Não consigo provar isso.
Talvez as páginas japonesas tenham ajudado.
Talvez uma pesquisa os tenha levado a um artigo em inglês.
Talvez alguém tenha partilhado um link.
Talvez tenham encontrado o site por um caminho completamente diferente.
Não tenho esses dados de attribution, por isso não vou fabricar a partir deles um SEO case study limpo que os dados não suportam.
O que consigo confirmar é muito mais simples: publiquei o blog em vários idiomas e, mais tarde, uma publicação japonesa considerou-o suficientemente interessante para o incluir numa seleção editorial.
Isso já é um bom resultado.
É especialmente satisfatório porque a localization também era uma experiência que inicialmente parecia exigir muito trabalho para um retorno incerto.
A menção teve importância porque foi uma validação independente
Quando digo “validação”, não quero dizer que a Levtech tenha provado que tudo o que escrevo está correto.
Não fizeram auditoria à minha codebase nem reproduziram todas as experiências.
O que importava era algo mais modesto.
Alguém do outro lado do mundo, a escrever para um público a quem eu próprio não conseguiria dirigir-me na sua língua, encontrou valor suficiente no meu trabalho para o resumir aos seus leitores.
Não lhes fiz pitch.
Não escrevi os artigos originais para a Levtech.
Não esperava aparecer numa seleção japonesa.
É isso que torna o resultado significativo para mim.
Sugere que um artigo técnico muito específico não precisa necessariamente de uma audiência enorme para valer a pena publicar.
Precisa de ser útil para o leitor certo.
Um developer deve começar um blog em 2026?
Para mim, sim — com uma condição importante.
É preciso realmente querer escrever alguma coisa.
Eu não recomendaria começar um blog técnico apenas porque alguém disse que todos os developers precisam de uma “marca pessoal”.
Também não o começaria à espera de rendimento passivo.
E não o criaria só para o encher com explicações genéricas sobre tecnologias que já têm documentação melhor.
Mas se o seu trabalho produz repetidamente coisas que gostaria de ter encontrado quando começou, isso é diferente.
Escreva-as.
Escreva sobre aquela falha estranha em produção.
Escreva sobre a otimização que demorou três dias mais do que esperava.
Escreva sobre o benchmark que contradisse a sua suposição.
Escreva sobre a abordagem que parecia elegante e falhou.
Escreva sobre a implementação final, mas explique também porque a implementação óbvia não era suficiente.
Essas são as partes difíceis de fabricar a partir de conhecimento genérico.
A IA dá-me mais material para escrever, não menos
A IA não me fez pensar que os blogs técnicos se tornaram obsoletos.
No meu caso, aconteceu quase o contrário.
Consigo investigar mais ideias porque obter uma implementação ou explicação inicial é mais rápido do que antes.
Mas iterações mais rápidas também criam mais evidência: mais variantes, mais logs, mais benchmarks, mais tentativas falhadas e mais coisas que têm de ser verificadas.
Esse material bruto só ganha valor depois de alguém fazer o trabalho de decidir o que é verdade e o que é importante.
Uma conversa com IA com 500 mensagens não é automaticamente conhecimento.
Um script que finalmente sobrevive a testes reais, acompanhado de uma explicação das 20 versões que não sobreviveram, pode ser.
É essa diferença que quero capturar no blog.
Publicar é a minha forma de impedir que trabalho útil desapareça
A maior parte do trabalho técnico é surpreendentemente temporária.
Um bug difícil é corrigido.
O terminal fecha.
O deployment é bem-sucedido.
A conversa desce no histórico.
Seis meses depois, talvez nem eu me lembre porque a implementação final tem exatamente aquela forma.
Escrever muda isso.
Obriga-me a reconstruir o raciocínio enquanto a evidência ainda existe.
Cria algo pesquisável.
Dá-me uma referência para o meu próprio trabalho futuro.
E, ocasionalmente, aparentemente chega a alguém que eu nunca esperaria — incluindo uma publicação de engenharia numa língua que não falo.
Ainda não tenho uma razão sofisticada para manter este blog.
Gosto de aprender.
Gosto de construir coisas.
Gosto de ir fundo demais em problemas que inicialmente pareciam simples.
E depois de passar dezenas, por vezes mais de cem horas, para chegar a uma resposta útil, já não quero que essa resposta morra dentro de uma janela de chat.
Para mim, é razão suficiente para a publicar.
Se o seu trabalho também produz este tipo de conhecimento conquistado com esforço, penso que talvez seja razão suficiente para si também.