Durante mucho tiempo no tuve claro que este sitio necesitara un blog.
Ya paso la mayor parte de mi jornada resolviendo problemas. Algunos son tareas normales de frontend o backend. Otros se vuelven mucho más específicos: codificación de imágenes, comportamiento del navegador, experimentos de SEO, fallos de infraestructura, desarrollo asistido por IA, procesamiento multimedia o algún problema extraño de producción que empieza con una pregunta sencilla y termina convirtiéndose en varios días de investigación.
Después de todo eso, escribir otros cuantos miles de palabras puede parecer innecesario.
¿Quién va a leerlo?
¿Qué obtengo yo de ello?
¿Por qué no resolver simplemente el problema y seguir adelante?
Al final encontré una respuesta que me bastaba: parte de este trabajo cuesta demasiado como para tirarlo.
Un problema difícil puede contener un artículo entero antes de que me dé cuenta
Mis artículos normalmente no empiezan con la idea de «esta semana necesito publicar algo».
Empiezan con un problema.
A veces viene de mi trabajo. A veces, de uno de mis propios proyectos. Otras veces simplemente me interesa algo que no entiendo y sigo profundizando hasta comprenderlo mucho mejor.
El procesamiento de imágenes me ha llevado muchas veces por ese camino.
Al principio, una tarea puede sonar casi ridículamente sencilla:
Toma estas imágenes y haz que pesen menos.
Puedes pedirle un script a un modelo de IA y obtenerlo casi al instante.
Eso no significa que tengas un buen pipeline de procesamiento de imágenes.
La primera versión puede ignorar las diferencias entre JPEG, PNG, WebP y contenido animado. Puede usar un único valor de calidad para todo. Puede ampliar imágenes sin necesidad. Puede gestionar mal la transparencia. Puede conservar metadatos que querías eliminar o destruir los que querías mantener. Puede optimizar solo el tamaño sin medir el deterioro visual. Puede funcionar perfectamente con diez archivos de prueba y convertirse en un error muy caro a una escala mucho mayor.
Que un script termine correctamente no lo convierte en un sistema en el que confío.
De esa diferencia nacen muchos de mis artículos.
Mi flujo de trabajo con IA es mucho más lento que «preguntarle a ChatGPT la respuesta»
Utilizo mucho una cuenta de pago de ChatGPT cuando trabajo con problemas de este tipo.
Una sola conversación puede durar días o semanas. Pregunto, pruebo propuestas, devuelvo resultados, cuestiono supuestos, reviso código, encuentro otro caso límite, cambio la implementación, vuelvo a ejecutarla, comparo el resultado y repito.
En investigaciones especialmente profundas he llegado a acumular más de 100 horas de trabajo alrededor del mismo problema general.
Eso no significa que pase 100 horas esperando a que un modelo de IA descubra mágicamente la respuesta.
El proceso es iterativo.
Suele parecerse más a esto:
- Describo el problema.
- El modelo propone una solución inicial.
- La ejecuto con datos reales.
- Algo resulta débil, ineficiente o simplemente incorrecto.
- Devuelvo la evidencia.
- Cambiamos el enfoque.
- Vuelvo a probarlo.
- Aparece otro caso límite.
- Repetimos.
Ese ciclo puede repetirse muchas veces.
El resultado útil no suele ser el primer script, sino el conjunto acumulado de fallos, mediciones, correcciones y decisiones que lo rodearon.
La IA abarató la generación de un punto de partida. No abarató la verificación
Por eso me parece demasiado simple la discusión habitual sobre el contenido técnico escrito con IA.
Sí, un modelo puede generar un tutorial plausible con enorme rapidez.
También puede generar código que parece completamente razonable y falla justo en las situaciones que importan.
En problemas técnicos muy específicos casi nunca quiero la primera respuesta plausible. Quiero saber qué ocurre cuando la ejecuto de verdad.
Si estoy construyendo un pipeline de imágenes, quiero revisar tamaños de salida y calidad visual. Quiero saber qué ocurre con distintos formatos de origen. Quiero probar dimensiones poco habituales, alpha, animaciones y entradas corruptas. Quiero entender qué supuestos está haciendo la implementación.
Si el script va a acabar procesando una colección enorme, todo eso importa todavía más.
Diez millones de imágenes es un ejemplo deliberadamente extremo, no una afirmación sobre el tamaño de un dataset concreto mío. Pero ilustra bien el problema: un pequeño error sistemático multiplicado diez millones de veces deja de ser pequeño.
El coste de generar código se ha desplomado.
El coste de decidir si ese código merece ejecutarse a escala no.
El chat es material de investigación, no el artículo terminado
Después de una investigación larga, el historial del chat puede contener una cantidad absurda de información.
Puede haber:
- enfoques que fracasaron;
- código que después fue sustituido;
- resultados útiles de benchmarks;
- logs;
- malentendidos;
- correcciones;
- explicaciones de comportamientos poco claros;
- comparaciones entre alternativas;
- casos límite que al principio no había considerado;
- y las reglas finales en las que acabé confiando.
Dejar todo eso encerrado en una conversación privada me parece un desperdicio.
Así que extraigo las partes útiles y las convierto en un artículo.
El artículo no es una transcripción de la conversación. La mayor parte de la conversación nunca debería convertirse en artículo.
Un buen artículo técnico necesita otra pasada: eliminar callejones sin salida que no enseñan nada, conservar los que sí explican algo importante, verificar afirmaciones, reconstruir la cronología, separar observación de explicación y convertir el resultado en algo que otro desarrollador pueda utilizar de verdad.
Esa etapa editorial importa.
La IA puede participar en ella, pero la evidencia sigue viniendo del trabajo.
El procesamiento de imágenes me enseñó hasta dónde puede llegar un problema «simple»
La optimización de imágenes probablemente sea el ejemplo más claro de mi propio trabajo.
Le he dedicado tanto tiempo que lo que al principio parecía una colección de ajustes del codificador se convirtió gradualmente en un problema de sistemas mucho mayor.
Las preguntas cambian rápido.
¿Con qué formato de origen estoy trabajando?
¿Es animado?
¿Debo cambiar las dimensiones?
¿Cómo elijo la calidad?
¿Qué métrica debe decidir si la pérdida de calidad es aceptable?
¿Funciona un único umbral de calidad con imágenes completamente distintas?
¿Cómo evito el upscaling?
¿Qué metadatos deben sobrevivir?
¿Qué ocurre con la transparencia?
¿Cómo debería validar la salida?
¿Compensa realmente el archivo más pequeño el coste adicional de codificación?
¿Qué ocurre cuando cambia la población de entrada?
Por eso soy escéptico con los scripts de cinco líneas de «optimización definitiva de imágenes».
Claro que pueden procesar una imagen.
Eso es distinto de construir un pipeline cuyos compromisos entiendes.
Para mis cargas actuales con muchas imágenes, AVIF suele ser el formato al que miro primero. Es una regla basada en el tipo de proyectos en los que trabajo, no una afirmación de que todas las webs del planeta deban borrar mañana todos los formatos antiguos. Los requisitos de compatibilidad, el material de origen, la latencia, el coste del encoder y la arquitectura de entrega pueden cambiar la respuesta.
Lo interesante no es declarar ganador a un formato.
Es entender suficientemente bien la carga de trabajo para tomar la decisión conscientemente.
Quiero profundizar del mismo modo en procesamiento de vídeo. Aún no he llegado a ese punto. Eso también forma parte de lo interesante: cada vez que creo haber llegado al fondo de un problema aparece otra capa.
Entonces un sitio japonés encontró el blog
No esperaba un beneficio concreto por publicar estos artículos.
Este blog no me produce un retorno económico significativo. Lo hago porque me gusta el proceso y porque prefiero conservar trabajo útil antes que verlo desaparecer en chats antiguos y en el historial de la terminal.
Entonces ocurrió algo que realmente no esperaba.
El 17 de septiembre de 2026, el sitio japonés Levtech Freelance publicó una recopilación con un título que podría traducirse aproximadamente como «Blogs recomendados para ingenieros que quieren mejorar sus habilidades».
El artículo de Levtech Freelance incluyó JSVar junto a varios otros blogs de ingeniería.
Levtech forma parte de un gran ecosistema japonés de carreras de TI, y Levtech Freelance se centra en apoyar y conectar a ingenieros de TI freelance con oportunidades. Para mí, lo interesante no era simplemente recibir un backlink. Era ver qué partes de mi trabajo un equipo editorial externo consideraba dignas de describir.
Su sección sobre JSVar destacó especialmente tres artículos.
Uno explicaba por qué Codex y TypeScript me parecieron una buena combinación en desarrollo de producción, sobre todo porque los tipos y el feedback del compilador de TypeScript pueden exponer problemas en código generado.
Otro trataba sobre traducir el blog a 20 idiomas con ChatGPT y ver cómo visitantes procedentes de buscadores llegaban directamente a páginas localizadas desde distintos países.
El tercero era mi experimento de publicar 10.000 páginas SEO generadas con IA, que terminó convirtiéndose en una historia de fracaso más que de crecimiento fácil.
La selección me hizo gracia porque son tres artículos muy distintos, pero comparten el mismo patrón.
Todos se basan en algo que realmente hice.
No sé exactamente cómo me encontró Levtech
Aquí hay una historia muy tentadora.
No hablo japonés.
Mi sitio tiene una versión en japonés.
Una publicación japonesa de ingeniería encontró el sitio.
Por tanto, traducir el blog al japonés hizo que Levtech lo descubriera.
No puedo demostrarlo.
Puede que las páginas japonesas ayudaran.
Puede que una búsqueda los llevara a un artículo en inglés.
Puede que alguien compartiera un enlace.
O puede que llegaran al sitio por otra vía completamente distinta.
No tengo esos datos de atribución, así que no voy a fabricar a partir de ello un caso de estudio de SEO limpio que los datos no permiten sostener.
Lo que sí puedo confirmar es mucho más sencillo: publiqué el blog en varios idiomas y más tarde una publicación japonesa lo consideró suficientemente interesante como para incluirlo en una selección editorial.
Eso ya es un buen resultado.
Y me resulta especialmente satisfactorio porque la localización fue otro experimento que inicialmente parecía requerir mucho trabajo para un beneficio incierto.
La mención importó porque fue una validación independiente
No uso «validación» en el sentido de que Levtech demostrara que todo lo que escribo es correcto.
No auditaron mi código ni reprodujeron cada experimento.
Lo importante era algo más modesto.
Alguien al otro lado del mundo, escribiendo para un público al que yo no podría dirigirme en su idioma, encontró suficiente valor en mi trabajo como para resumirlo para sus lectores.
Yo no se lo propuse.
No escribí aquellos artículos originales pensando en Levtech.
No esperaba aparecer en una recopilación japonesa.
Eso hace que el resultado sea significativo para mí.
Sugiere que un artículo técnico muy específico no necesita necesariamente una audiencia enorme para merecer la pena.
Necesita ser útil para el lector adecuado.
¿Debería un desarrollador empezar un blog en 2026?
Para mí, sí, pero con una condición importante.
Tienes que querer realmente dejar algo por escrito.
No recomendaría empezar un blog técnico solo porque alguien te haya dicho que todo desarrollador necesita una «marca personal».
Tampoco lo empezaría esperando ingresos pasivos.
Ni lo llenaría de explicaciones genéricas de tecnologías que ya cuentan con documentación mejor.
Pero si tu trabajo produce repetidamente cosas que te habría gustado encontrar cuando empezabas, eso es distinto.
Escríbelas.
Escribe sobre ese extraño fallo de producción.
Escribe sobre la optimización que tardó tres días más de lo previsto.
Escribe sobre el benchmark que contradijo tu supuesto.
Escribe sobre el enfoque que parecía elegante y fracasó.
Escribe sobre la implementación final, pero explica también por qué la implementación obvia no era suficiente.
Esas son las partes difíciles de fabricar a partir de conocimiento genérico.
La IA me da más material sobre el que escribir, no menos
La IA no me ha hecho pensar que los blogs técnicos estén obsoletos.
En mi caso ha ocurrido casi lo contrario.
Puedo investigar más ideas porque obtener una implementación o explicación inicial es más rápido que antes.
Pero una iteración más rápida también produce más evidencia: más variantes, más logs, más benchmarks, más intentos fallidos y más cosas que hay que comprobar.
Ese material en bruto solo adquiere valor cuando alguien hace el trabajo de decidir qué es cierto y qué importa.
Una conversación con una IA que contiene 500 mensajes no se convierte automáticamente en conocimiento.
Un script que finalmente supera pruebas reales, acompañado de una explicación de las 20 versiones que no lo hicieron, sí puede convertirse en ello.
Esa diferencia es lo que quiero capturar con el blog.
Publicar es mi forma de evitar que el trabajo útil desaparezca
La mayor parte del trabajo técnico es sorprendentemente temporal.
Se corrige un bug difícil.
Se cierra la terminal.
El despliegue termina bien.
La conversación baja en el historial.
Seis meses después, puede que ni yo recuerde por qué la implementación final tiene esa forma.
Escribir cambia eso.
Me obliga a reconstruir el razonamiento mientras la evidencia sigue existiendo.
Crea algo que se puede buscar.
Me da una referencia para mi propio trabajo futuro.
Y, aparentemente, de vez en cuando llega a alguien que nunca habría esperado, incluida una publicación de ingeniería en un idioma que no hablo.
Sigo sin tener una razón sofisticada para mantener este blog.
Me gusta aprender.
Me gusta construir cosas.
Me gusta profundizar demasiado en problemas que al principio parecían sencillos.
Y después de pasar decenas, o a veces más de cien horas, intentando llegar a una respuesta útil, ya no quiero que esa respuesta muera dentro de una ventana de chat.
Para mí, esa es razón suficiente para publicarla.
Si tu trabajo también produce ese tipo de conocimiento ganado con esfuerzo, creo que quizá sea una razón suficiente para ti.