Acelerado por IA, en manos humanas: mi flujo de trabajo real

Al principio del trabajo en yesid.dev, elegí un límite claro para el CMS: el contenido compartido y recurrente de la interfaz debía venir del CMS en lugar de permanecer en archivos del frontend. Claude produjo la implementación, y yo revisé los archivos para comprobar si respetaban ese límite. Encontré texto compartido que seguía incrustado directamente en el frontend. El texto incrustado y el texto administrado por el CMS pueden producir los mismos píxeles. Una revisión en el navegador demuestra que la página se renderiza, no qué sistema es responsable del contenido. La revisión de los archivos mostró que la implementación todavía no coincidía con el modelo de contenido que yo había elegido.

Claude fue mi principal herramienta de implementación para yesid.dev y transit.yesid.dev. Codex se encargó sobre todo de revisar el trabajo y, a veces, intervino como implementador de respaldo. Yo supervisé ambos proyectos de principio a fin y tomé las decisiones de arquitectura. Mantuve el contexto de los proyectos, decidí cómo debían encajar las partes, di instrucciones, inspeccioné los resultados, encontré problemas e hice avanzar el trabajo.

El trabajo pasó a ser más de gestión. En lugar de escribir yo mismo el código de cada implementación, dirigía los proyectos, mantenía la arquitectura a la vista y revisaba lo que recibía.

El repositorio de yesid.dev también cuenta hoy con verificaciones automatizadas del contenido generado y las advertencias de Svelte. El hook de pre-commit y la CI de los PR comparan los módulos generados por el CMS con el manifiesto registrado. La CI de los PR ejecuta esta verificación para los pull requests dirigidos a main o develop. La comparación detecta las diferencias normales entre los módulos y el manifiesto, pero comprueba su coherencia, no si el CMS realmente produjo los archivos. El hook local puede omitirse, y una edición coordinada del módulo y el manifiesto puede hacer que ambos sigan coincidiendo.

La verificación web usa un umbral configurable específicamente para las advertencias de Svelte. Falla cuando el número de advertencias reportadas supera ese umbral. Estos controles cubren condiciones reproducibles del repositorio. No deciden si la arquitectura del CMS es correcta ni si un contenido debe estar en el frontend. Esa sigue siendo una decisión de proyecto y arquitectura.

Mi proceso empieza con una conversación y mis divagaciones. La IA organiza el material en un esqueleto y propone redacción por bloques. Un artículo lleva mi nombre solo después de que reviso y corrijo la estructura, las afirmaciones y la redacción, uso esas correcciones en otro borrador de IA, leo cada bloque de principio a fin y decido qué queda.

Si un cliente quiere saber si entiendo lo que publico, que me pregunte sobre cualquier cosa de este sitio.

La IA es una herramienta entre muchas. No es el resultado final. Los resultados son yesid.dev, transit.yesid.dev y los sistemas que hacen funcionar su contenido y sus servicios.

Después de desplegar Transit, también tuve que mantenerlo funcionando y pagar la factura mensual de infraestructura.

Este es el capítulo 4 de una serie de seis capítulos. Capítulos 1–3: quién soy. Capítulos 4–6: lo que construyo. Anterior: Pensar en matrices · Siguiente: De 50 $ a 0 $: una VM Oracle Always Free.