Inicio / Artículos / Un flujo de trabajo asistido por IA para enviar un sitio web pequeño a Cloudflare

Un flujo de trabajo asistido por IA para enviar un sitio web pequeño a Cloudflare

Un flujo de trabajo reutilizable y plantillas de prompts para diseñar, iterar y desplegar un sitio pequeño con la ayuda de un asistente de programación basado en IA, utilizando las versiones gratuitas de GitHub y Cloudflare.

1981 palabras

Un pequeño sitio web informativo ya no requiere un proceso de desarrollo largo. Con la ayuda de un asistente de programación basado en IA que se encarga de gran parte de la implementación, una sola persona puede pasar de una idea preliminar al código fuente en GitHub, realizar despliegues automáticos a través de Cloudflare y tener un dominio personalizado activo en aproximadamente medio día de trabajo concentrado. La parte difícil pasa de escribir código a decidir qué se desea y ofrecer retroalimentación precisa sobre lo obtenido. Esta guía describe ese flujo de trabajo paso a paso, con plantillas de prompts que se pueden adaptar para las fases de diseño, logotipo, revisión e iteración, y deja claro en qué puntos este enfoque deja de ser adecuado.

Comience por el propósito, no por un framework

La primera pregunta lógica para un desarrollador es cuál tecnología utilizar: React, Next.js, un generador de sitios estáticos o algo distinto. Cuando un asistente puede generar la mayor parte de la implementación, esa pregunta cobra mucha menos importancia que otra más simple: ¿qué debe hacer realmente el sitio?

Para una primera versión de un sitio personal o de consultoría, la respuesta puede ser breve. Los visitantes deben comprender qué representa el sitio, poder encontrar sus artículos e información relevante, y saber cómo ponerse en contacto. Eso constituye un alcance completo. Anotarlo primero proporciona tanto a usted como al modelo una referencia clara para todas las decisiones posteriores, y evita que el primer lanzamiento se convierta en un proyecto de rediseño.

Cuando no tienes un diseño en mente

Muchas personas comienzan sin una especificación de diseño, y eso está bien. En lugar de maquetas, describa la experiencia que desea: por ejemplo, profesional, moderna, limpia, espaciosa y orientada a la tecnología, sin que parezca futurista por sí misma. El asistente convierte esa descripción en un primer boceto visual.

Una vez que algo aparece en la pantalla, los comentarios son fáciles de dar porque se reacciona a algo concreto en lugar de imaginarlo:

  • El logotipo no coincide con la marca.
  • La imagen del banner está recortada.
  • Una sección parece abarrotada.
  • Parte de la página debe quedar oculta por ahora.

Una secuencia de reacciones como estas es el proceso de diseño. No se necesita vocabulario especializado en diseño, solo la capacidad de darse cuenta de lo que no está bien y expresarlo.

El ciclo de retroalimentación es más importante que la primera solicitud

No existe una instrucción perfecta única. La primera salida tiene como objetivo proporcionarte algo a lo que responder. Las instrucciones posteriores se vuelven más específicas y concretas: corregir el logotipo, ajustar el recorte del banner, ocultar secciones inacabadas, renombrar los elementos de navegación, probar los enlaces y verificar el diseño para móviles.

La calidad proviene de varias rondas cortas y específicas, en lugar de de una sola solicitud extensa. Las rondas breves también facilitan detectar cuándo el modelo ha modificado algo que no solicitaste.

Una instrucción maestra para la primera versión

Una instrucción inicial útil describe el proyecto y luego pide al modelo que proponga un diseño y lo justifique antes de generar el código. Un plantilla podría incluir estas partes:

  • El nombre de la marca, empresa o proyecto.
  • El propósito: qué debe ayudarte a lograr el sitio.
  • La audiencia: para quién está dirigido.
  • El mensaje principal que un visitante debe llevarse en los primeros 15 a 20 segundos.
  • La dirección visual, como profesional, minimalista, de alta gama, creativa o orientada a la tecnología, y si prefiere un fondo claro, oscuro o neutro.
  • Expectativas básicas: tipografía limpia, suficiente espacio en blanco, una fuerte jerarquía visual y un diseño que funcione en teléfonos.
  • Una declaración honesta de que aún no se han elegido los colores, fuentes ni la estructura de la página.
  • Luego pida al modelo que proponga, según el propósito y la audiencia:

    1. Una paleta de colores.
    2. Una dirección tipográfica.
    3. Una estructura para la página principal.
    4. Un concepto para la sección principal.
    5. La navegación.
    6. Las secciones de contenido recomendadas.
    7. Los llamados a la acción.
    8. El estilo visual general.

    Termina indicándole que explique el diseño propuesto y por qué se adapta al público antes de escribir cualquier código, y que genere la primera versión funcional solo una vez que apruebes esa dirección. Separar la propuesta de la implementación es el paso clave: es mucho más económico rechazar una paleta en texto que eliminarla del CSS generado.

    Trata el logotipo como una tarea independiente

    Un logotipo también debe funcionar fuera del sitio web: en perfiles sociales, en diapositivas y en documentos. Mezclarlo con la solicitud del sitio tiende a generar algo ajustado únicamente para el encabezado, así que asigna una solicitud específica al branding.

    Pida un concepto de logotipo sencillo que sea minimalista, contemporáneo, profesional y distintivo, además de reconocible en tamaños pequeños. Indique dónde debe funcionar bien: sitios web, avatares en redes sociales, presentaciones, documentos, y tanto fondos claros como oscuros. Describa brevemente la idea que representa la marca y luego solicite:

    1. Un concepto visual.
    2. Una dirección tipográfica.
    3. Una paleta de colores.
    4. Una idea para un ícono o monograma.
    5. Una versión para fondos claros.
    6. Una versión para fondos oscuros.
    7. Una explicación de por qué el diseño se adapta a la marca.

    Añada una restricción explícita para evitar ilustraciones o símbolos complejos que dependan de detalles finos, ya que estos se desdibujan al reducirse al tamaño del favicon.

    Deje que el asistente se encargue de la implementación mientras usted se mantiene en el nivel de intención

    Una vez definida la dirección a seguir, un asistente de programación (ChatGPT y Codex, en el escenario del que proviene este flujo de trabajo) puede encargarse de la mayor parte de la implementación. La ventaja es que las instrucciones pueden referirse a lo que se desea lograr en lugar de indicar exactamente qué archivo y línea modificar:

    • Se divide el banner por la mitad.
    • Por ahora, comente estas secciones.
    • Cambie el nombre de este botón.
    • Haga que este botón lleve al apartado correspondiente.
    • Procure que el logotipo coincida con la ilustración original.

    Aún así, usted revisa cada resultado, pero ya no necesita navegar por el código manualmente para cada pequeño ajuste.

    Registre el dominio cuanto antes y siga desarrollando localmente

    Registrar un dominio es rápido: buscar, verificar la disponibilidad, registrar y pagar. Hacer que esté completamente listo para usarlo puede llevar más tiempo. En el escenario descrito aquí, transcurrieron unas 24 horas hasta que todo se resolvió como se esperaba; la demora que observes dependerá del registrador y de la propagación DNS.

    Esa espera no tiene por qué obstaculizar el desarrollo. Sigue creando y probando con una versión preliminar local mediante un ciclo continuo: cambiar, ver la previsualización, revisar, corregir y probar de nuevo. Trabajar localmente también significa que los experimentos inacabados nunca se exponen públicamente, y describir los cambios a un nivel más alto te evita tener que buscar entre múltiples archivos para ajustar líneas individuales.

    Utiliza el modelo como revisor, no solo como herramienta de creación

    Una vez que exista la primera versión, pídale al asistente que la critique. La instrucción para la revisión debe asignarle un rol, evitar que rediseñe todo y exigir resultados prioritarios y accionables.

    Pídale que analice una captura de pantalla como diseñador senior de UI y UX, e identifique, sin un rediseño innecesario, las mayores oportunidades de mejora:

    • Diseño general: espaciado, alineación y equilibrio visual total.
    • Jerarquía y tipo de elementos: claridad con la que se guía la vista, elección de fuentes y legibilidad.
    • Consistencia: colores y elementos de marca en toda la página.
    • Funcionamiento en pantallas más pequeñas.
    • Llamados a la acción: si cada uno es evidente y está redactado con claridad.

    Solicite que los hallazgos se clasifiquen, y que cada uno indique qué aspecto parece débil, por qué es importante y exactamente qué se debe cambiar. Además, limite las modificaciones a aquellas que mejoren de manera significativa la profesionalidad y la usabilidad. Esa última frase evita que la revisión se convierta en una lista de preferencias estéticas.

    La iteración es donde ocurre la mayor parte del trabajo

    Después del diseño inicial, muy poco trabajo implica crear algo nuevo. Casi todo consiste en mejorar lo que ya existe, y las instrucciones breves y precisas son las más efectivas en este caso. Un plantilla fiable para la iteración se ve así:

    • Una lista numerada de los cambios específicos que desea realizar, uno por línea.
    • Una instrucción clara de no rediseñar secciones no relacionadas y de conservar todo lo que ya funciona.
  • Una lista de verificación que el modelo debe ejecutar después de los cambios: revisar el diseño para escritorio, revisar el diseño para móviles, confirmar que los enlaces de navegación funcionen, asegurarse de que cada botón lleve al destino correcto, comprobar que nada esté oculto o recortado por error, e informar sobre cualquier problema restante que detecte.
  • Merece especial énfasis la instrucción de preservación. Los asistentes tienden a “mejorar” el código cercano al corregir lo que se les pide, y una restricción explícita reduce esa tendencia. La lista de autoverificación no reemplaza tu propia revisión, pero detecta regresiones obvias antes de que las notes.

    De la vista previa local a un sitio en vivo con GitHub y Cloudflare

    Una vez que el sitio funcione localmente, sube su código fuente a un repositorio de GitHub. GitHub te proporciona un historial de versiones y una forma segura de revertir cualquier cambio que haga el asistente.

    A continuación, conecte ese repositorio a Cloudflare para que cada actualización en el repositorio active automáticamente un proceso de compilación e implementación. A partir de ese momento, publicar consiste simplemente en hacer un commit y enviar los cambios. Para un sitio informativo pequeño, la versión gratuita de Cloudflare fue suficiente en este escenario; verifique los límites del plan actual según sus necesidades.

    Cuando el dominio esté activo y sus registros DNS estén configurados, asocie el dominio personalizado al proyecto implementado. En ese punto, al introducir el dominio en un navegador se mostrará el sitio en línea.

    Costos y casos en los que no es adecuado

    Para este tipo de proyecto, los costos operativos son modestos:

    • Registro de dominio: aproximadamente 12 dólares al año en este caso.
    • GitHub: gratuito.
    • Cloudflare: la versión gratuita fue suficiente.
    • Herramientas de IA: el costo de su suscripción a ChatGPT u otro asistente.

    Aparte de la suscripción al asistente, el dominio es prácticamente el único costo de infraestructura.

    Este enfoque no es adecuado para todas las aplicaciones. Cualquier cosa que involucre pagos, datos personales sensibles, autenticación compleja, bases de datos o entornos regulados requiere una ingeniería adecuada: modelado de amenazas, revisión del código por parte de alguien que comprenda cada línea, pruebas y monitoreo operativo. Sin embargo, para portafolios, páginas de aterrizaje, sitios de consultoría, prototipos y sitios simples de contenido, la barrera de entrada es drásticamente más baja que antes.

    Qué decide y qué no decide el asistente

    El asistente se encarga de una gran parte de la ejecución: escribir y editar código, transformar los comentarios del diseño en cambios, solucionar problemas visuales y explicar pasos técnicos desconocidos. Varias decisiones siguen siendo exclusivamente humanas:

    • Qué debe representar el sitio.
  • Qué contenido es importante.
  • Si el diseño visual resulta adecuado.
  • Cuándo la primera versión está lo suficientemente lista para lanzarse.
  • Eso elimina el cuello de botella. La pregunta limitante deja de ser si se puede desarrollar técnicamente el sitio y pasa a ser si se puede decidir con claridad qué se desea. La barrera de implementación disminuye; la necesidad de juicio, no.

    Puntos clave

    • Defina el propósito, el público objetivo y el mensaje central antes de elegir cualquier tecnología.
    • Pida al modelo que proponga y justifique un diseño antes de escribir código, y apruebe explícitamente la dirección a seguir.
    • Trate el logotipo por separado para que funcione en todos los medios, no solo en el encabezado del sitio.
    • Depienda de rondas de iteración cortas y específicas, con la restricción de “preservar todo lo demás” y una lista de verificación propia.
    • Utilice al asistente tanto como crítico como colaborador, con comentarios priorizados y prácticos.
    • Ponga el código en GitHub y deje que Cloudflare lo despliegue con cada actualización, de modo que el control de versiones y el alojamiento sean automáticos.
    • Reserve este enfoque ligero para sitios de bajo riesgo. El valor radica en cómo las diferentes partes se conectan en un único flujo de trabajo: usted controla el propósito, el juicio y la aprobación, el asistente se encarga de la ejecución, GitHub proporciona el historial y Cloudflare realiza la publicación.