Cuando empecé este blog, dejé muchas cosas sin terminar.
No porque no me importaran.
Sino porque el objetivo no era construir el sitio perfecto.
El objetivo era crear un lugar donde pudiera escribir field notes.
Esa diferencia importaba.
En el primer post, Dónde está el impacto real (y dónde no), escribí sobre la decisión de dejar de pulir todo lo que estaba alrededor del blog y avanzar con algo que fuera suficientemente bueno. Fuentes, colores, templates, detalles de UI, estructura y pequeñas decisiones de diseño eran cosas importantes eventualmente, pero ninguna era la razón por la que el blog existía.
El impacto real era tener un lugar donde la escritura pudiera suceder.
Esa decisión fue correcta.
Pero también dejó un rastro.
El trabajo alrededor del trabajo
Después de que el blog quedó en línea, los detalles pendientes no desaparecieron.
Se convirtieron en el trabajo alrededor del trabajo.
Pequeñas inconsistencias visuales.
Templates que se sentían prestados.
Código repetido para i18n.
Imágenes Open Graph demasiado manuales.
Un switcher de idioma que podía ser más claro.
Espacios que se sentían casi bien, pero no del todo.
Pequeñas piezas de deuda técnica fáciles de ignorar porque el objetivo principal ya se había cumplido.
Nada de eso bloqueaba escribir.
Pero todo eso seguía afectando la experiencia.
Afectaba cómo se sentía el sitio, qué tan mantenible era y cuánta fricción aparecía cada vez que quería cambiar algo.
Ese tipo de deuda es fácil de posponer porque casi nunca parece urgente.
No rompe producción.
No despierta a nadie con una alerta.
Simplemente espera.
Y cada vez que vuelves al proyecto, te recuerda en silencio que el sistema no es tan cómodo de trabajar como podría ser.
Esperando la herramienta correcta
A veces dejamos cosas sin hacer por flojera.
Pero muchas veces las dejamos sin hacer porque todavía no tenemos la herramienta correcta, el contexto correcto o la energía adecuada para el problema.
En este caso, eso era parte de la historia.
Mucho del trabajo pendiente era frontend.
Puedo trabajar en frontend, pero no es mi punto más fuerte. Sé cuando un layout se siente raro. Sé cuando el espacio vertical no funciona. Sé cuando una UI cuesta más de lo que debería.
Pero traducir esa sensación en un sistema visual consistente, comportamiento responsive, mejores templates y una estructura más limpia requiere otro tipo de atención.
Ahí fue donde la IA ayudó.
No como reemplazo.
Como leverage.
Me ayudó a avanzar en partes del trabajo donde tenía suficiente expertise para evaluar el resultado, pero no siempre la fluidez suficiente para llegar ahí rápido.
Esa diferencia importa.
La IA no decidió qué debía ser el blog.
No sabía qué se sentía correcto para el sitio.
No sabía qué trade-offs importaban.
Ayudó a ejecutar, comparar, refinar y conectar piezas más rápido una vez que la dirección estaba clara.
La IA todavía necesita ownership
Hay una versión superficial de la conversación sobre IA que dice que simplemente va a reemplazar a las personas técnicas.
No me parece una conversación muy útil.
La pregunta más interesante es:
¿Qué tipo de trabajo se vuelve más fácil cuando aprendemos a usar bien la IA?
Estoy pensando en esa pregunta dentro del contexto del trabajo de ingeniería.
No en tareas aisladas sin consecuencias.
En el tipo de trabajo donde construimos y operamos servicios, conectamos sistemas, cargamos responsabilidades de producción, hacemos trade-offs entre equipos y seguimos cambiando cosas de las que otras personas o sistemas dependen.
Ese contexto importa porque la buena ingeniería casi nunca se trata solo de producir código.
Para mí, este fue un buen ejemplo.
La IA ayudó a limpiar páginas duplicadas de i18n.
Ayudó a mejorar el look and feel.
Ayudó a generar templates de Open Graph.
Ayudó a hacer más clara la sección de compartir.
Ayudó a convertir TODOs sueltos en cambios más pequeños y revisables.
Pero el trabajo todavía necesitó criterio.
Los prompts importaron.
Las preguntas importaron.
La capacidad de mirar una salida y decir “esto está cerca, pero todavía no” importó.
También importó notar cuando una solución se estaba volviendo demasiado compleja.
La IA puede producir mucho código muy rápido.
Eso solo es útil si alguien sigue siendo responsable de la dirección.
Sin ownership, la velocidad solo crea más cosas que limpiar después.
También hay una versión más pequeña y práctica de ese riesgo.
Algunas de las piezas frontend que cambié ahora funcionan mejor que antes, pero no puedo decir honestamente que entiendo de memoria cada detalle de cómo funciona cada una.
Eso no es un fracaso.
Pero es una señal.
El trabajo asistido por IA necesita mantenerse lo suficientemente localizado para que yo pueda seguirle el paso.
“Mejora este componente.”
“Limpia esta ruta duplicada.”
“Haz que este espaciado sea consistente.”
“Genera este template desde datos que ya confío.”
Esos son buenos prompts porque mantienen el trabajo revisable.
“Refactoriza todo el sitio” es un tipo de petición muy distinto.
Puede producir mucho movimiento, pero movimiento no es lo mismo que progreso si no puedo explicar qué cambió, por qué cambió y dónde tendría que arreglarlo después.
La forma paso a paso importa.
Cada cambio debería ser lo suficientemente pequeño para leerlo, probarlo, ajustarlo y hacerlo propio antes de pedir el siguiente.
La herramienta correcta cambia la forma del trabajo
Lo que cambió hoy no fue que los TODOs de pronto se volvieran importantes.
Ya eran importantes.
Lo que cambió fue que por fin tenía la herramienta correcta para que resolverlos fuera barato.
Ese patrón es familiar en ingeniería.
Parte de la deuda se queda ahí porque el costo de pagarla es demasiado alto comparado con el valor inmediato. Luego una mejor abstracción, una mejor plataforma, un mejor workflow, una mejor librería o una mejor herramienta cambia la ecuación.
El trabajo se vuelve lo suficientemente pequeño para hacerlo.
No porque el problema haya desaparecido.
Sino porque el camino para atravesarlo se volvió más claro.
Así se sintió este blog hoy.
El objetivo original seguía siendo el mismo: un lugar para escribir field notes.
Pero ahora el trabajo alrededor de ese objetivo está más limpio.
El sitio es más fácil de mantener.
La estructura multilenguaje es menos repetitiva.
El sistema visual se siente más intencional.
Las imágenes Open Graph se pueden generar en vez de hacerse a mano.
Los detalles alrededor de la escritura apoyan mejor a la escritura.
Eso vale la pena.
No antes del primer post.
Pero eventualmente.
Una herramienta no es una estrategia
La lección no es “usa IA para todo”.
La lección se parece más a esto:
La herramienta correcta puede desbloquear trabajo, pero todavía necesita las preguntas correctas.
Las herramientas no eliminan el criterio.
Mueven el criterio a otro lugar.
En vez de preguntar “¿puedo construir esto desde cero?”, la pregunta se vuelve:
¿Qué estoy tratando de resolver?
¿Qué debería mantenerse simple?
¿Qué vale la pena automatizar?
¿Qué debería generarse?
¿Qué debería seguir escrito a mano?
¿Cómo se ve “suficientemente bueno” ahora?
Esas preguntas siguen perteneciendo a la persona que hace el trabajo.
Y quizá esa es la forma más sana de pensar en la IA dentro del trabajo técnico.
No como magia.
No como amenaza.
Como otra herramienta que cambia lo que se vuelve posible cuando se usa con cuidado.
Hoy me ayudó a pagar la deuda alrededor del lugar donde escribo.
Mañana, el punto de este blog sigue siendo el mismo:
Seguir escribiendo.
Edit:
Después de todo el trabajo de mejora, publiqué este nuevo post.
Funcionaba localmente, pero no apareció en producción.
El problema era el campo de fecha en la metadata del post. Localmente, el post ya era visible. Pero cuando el sitio se construyó usando UTC en lugar de JST, esa misma fecha empujó el post hacia el futuro.
Ese tipo de bug es un buen reminder: mejorar un sistema con IA no elimina la necesidad de entender el sistema.