Saturdays.AI

Codex vs. MiniMax M2.1: replicando FoodCheck con dos IAs distintas

Miguel Guerrero — Fri, 06 Feb 2026 16:03:02 +0000

Comparar dos IAs programando no consiste solo en ver quién escribe mejor código. En la práctica, la diferencia más relevante aparece en cómo entienden una tarea abierta, cuánto contexto necesitan, qué decisiones toman cuando algo no está completamente especificado y cómo reaccionan a las correcciones.

Para demostrarlo, he realizado un experimento: he clonado FoodCheck, una app publicada en GitHub Pages, manteniendo la misma lógica de negocio y la misma interfaz. Este es el resultado.

El reto tenía la condición de que la app tenía que ser 100% estática. GitHub Pages no ejecuta servidores, no maneja variables de entorno del lado del servidor ni permite un backend tradicional.

La misma aplicación, dos IAs:

Codex (modelo gpt-5.1-codex-max), mi anterior asistente para desarrollar la app original.
MiniMax M2.1 (Chat-Agent), con quien he intentado replicarla simplemente dándole la URL para que la analizara.

El contraste entre ambos estilos fue más interesante de lo que esperaba.

FoodCheck como caso de estudio

FoodCheck no es solo una interfaz donde subes una foto y salen números. Por debajo hay decisiones de arquitectura críticas:

Visión artificial avanzada capaz de interpretar platos complejos, no solo objetos aislados.
Datos nutricionales y reglas que dependen del perfil de salud del usuario.
Persistencia local (registro diario) sin base de datos.
Despliegue estático obligatorio en GitHub Pages.

Estas restricciones no son detalles técnicos, son el producto. Y aquí es donde la forma de trabajar de cada IA marca la diferencia.

Codex como copiloto: muy potente, pero necesita tareas bien acotadas

Con Codex (gpt-5.1-codex-max) la sensación general fue la de tener un copiloto sólido. Con un matiz: si no divides el trabajo en tareas muy específicas, tiende a dar más rodeos. Y además, cuando la app crece, a veces se olvida de lo que hizo varios mensajes atrás y hay que volver a explicarle el contexto.

No es que se equivoque, sino que tiende a dispersarse si no le guías: necesita que dividas el problema en pasos más concretos, puede proponer soluciones intermedias que no encajan del todo con el despliegue final, y a veces insiste en patrones estándar del desarrollo web aunque choquen con las restricciones previas.

En mi caso, esto se notó especialmente en dos puntos: la detección de alimentos y la adaptación a una app estática.

La detección simulada como punto de partida

Igual que me ocurrió después con MiniMax, el punto de partida fue una detección ficticia simplificada, suficiente para que la UI y el flujo funcionen pero no aceptable si el objetivo es un análisis real de platos.

Aprendí que, si no insistes, la IA prefiere cerrar primero el producto visible y ya luego afinar el corazón técnico.

Llegar a una solución viable para GitHub Pages llevó iteraciones

Codex fue proponiendo ideas que en un entorno general de desarrollo web son normales (por ejemplo, configuraciones estilo .env o piezas propias de un backend). Pero en GitHub Pages eso es inviable.

Hizo falta iterar hasta aterrizar en una solución compatible con una app estática, donde la parte inteligente vive fuera del frontend (por ejemplo, vía servicios externos).

Iniciativa conservadora

Al no haberle dado una indicación explícita sobre la base de datos nutricional a utilizar, Codex optó por una base de datos local muy reducida, con valores nutricionales introducidos manualmente para unos pocos alimentos. Desde el punto de vista del desarrollo incremental, esta decisión tiene sentido, ya que permite avanzar sin dependencias externas y validar el flujo completo de la aplicación.

Sin embargo, también muestra el patrón de Codex como copiloto, tendiendo a elegir soluciones seguras si no se le fuerza a ampliar el alcance. La integración con una base de datos real como OpenFoodFacts no surgió por inferencia de dominio, sino solo cuando se le indicó de forma explícita. Codex no se equivoca, pero tampoco asume contexto de producto si no se le pide.

MiniMax M2.1 como agente: rapidez, foco y buena inferencia de contexto

Con MiniMax M2.1 el enfoque fue distinto desde el principio. Lo utilicé directamente para replicar FoodCheck.

La diferencia se vio enseguida, ya que en apenas unos minutos fue capaz de:

Hacer una primera lectura visual y lógica del producto original.
Crear la carpeta y los archivos (index.html, styles.css, app.js, README.md).
Desplegar una versión inicial funcional.

Y él solo se corregía sin que yo llegara a ver el error, solo veía el resultado final funcionando.

Base de datos nutricional sin instrucciones explícitas

Un detalle clave es que no tuve que mencionar OpenFoodFacts. El agente lo incluyó por iniciativa propia como fuente de datos nutricionales, demostrando una capacidad de inferencia superior sobre “qué necesita una app de este tipo”.

Del token en el frontend al diseño correcto del sistema

Al integrar LLaVA vía Cloudflare, MiniMax propuso inicialmente que el usuario introdujera su API token en la app. Es una solución rápida, pero muy mala desde el punto de vista de experiencia de usuario.

Cuando se le pidió una alternativa, el agente dio un salto importante: propuso un Cloudflare Worker como proxy para guardar el token de forma segura y mantener el frontend completamente estático.

En la práctica, este fue el punto donde MiniMax mostró más instinto de sistema y mayor capacidad para cerrar una solución completa de producto, no solo de código.

El punto débil de MiniMax: la fidelidad de la interfaz

Sin embargo, esta autonomía que brilló en el backend, fracasó en el frontend. Donde MiniMax M2.1 no consiguió cerrar el objetivo fue en la replicación exacta de la interfaz.

Aunque intentó replicar exactamente el diseño y llegó a desplegar versiones afirmando que lo había conseguido, seguía habiendo diferencias. Y esto conecta con una realidad práctica, y es que “parecido” es fácil, pero “idéntico” es más complejo.

Un agente puede aproximar estilos, pero para clonar una interfaz de forma fiable suele necesitar acceso directo al CSS original, assets y una validación visual metódica (capturas comparativas, inspección de estilos, etc.). Sin eso, se queda en “muy similar” rellenando los huecos de diseño con su propia imaginación.

El tropiezo compartido con el «mínimo viable»

A pesar de sus diferencias, ambas IAs cayeron en la misma trampa al inicio: la detección simulada o simplificada. Pero esto no es un error raro, es un patrón. Se construye el “cascarón” del producto, y luego se conecta el motor real.

Tanto Codex en su momento como MiniMax después propusieron por defecto usar TensorFlow.js + COCO-SSD. El problema es que COCO-SSD detecta tan solo ciertos alimentos concretos, pero no detecta alimentos de un plato de comida normal. Para una app de comida, eso es inútil.

Esto nos enseña una lección, y es que la IA tiende al camino de menor resistencia técnica. Prefiere cerrar el producto visible con una librería estándar antes que buscar la solución compleja (modelos multimodales) que realmente se necesita. Tuve que intervenir en ambos casos para forzar el uso de visión real.

Qué aporta Codex que MiniMax no

La principal fortaleza de Codex no es la velocidad ni la autonomía, sino el control. Cuando el desarrollador tiene claro el diseño, las restricciones y el resultado esperado, Codex se comporta de forma más predecible y menos creativa en el mal sentido. Rara vez inventa arquitectura, fuentes de datos o flujos no solicitados si se le han dado las órdenes correctas.

Esto reduce el riesgo de soluciones elegantes pero incorrectas desde el punto de vista del producto. El coste es que exige más trabajo previo: descomponer el problema, anticipar restricciones y guiar activamente el camino. Codex no suele cerrar el sistema por ti, pero respeta mejor lo que tú defines como correcto.

Qué aporta MiniMax que Codex no

MiniMax M2.1 destaca cuando el problema es abierto y el objetivo es tener algo completo funcionando lo antes posible. Toma la iniciativa para que el código sea una solución de mercado y no una estándar basada en lo que la mayoría de desarrolladores hace. Su capacidad para inferir contexto (como elegir OpenFoodFacts sin indicación explícita o proponer un Worker como proxy seguro) demuestra un mayor instinto de producto y de sistema.

Esta autonomía acelera enormemente las primeras fases, pero introduce un riesgo. El modelo tiende a decidir qué es suficientemente bueno si no se le dan métricas claras. MiniMax no espera a que definas todos los detalles, los asume. Eso lo convierte en un generador de soluciones, pero en un asistente que necesita auditoría constante cuando la fidelidad importa.

Además, MiniMax parece ser mejor detective. Si el código falla, MiniMax suele mirar el error y proponer una solución que arregla el problema actual e incluso problemas futuros que uno aún no ha visto. Codex suele limitarse a arreglar solo lo que le pides.

Conclusión: dos estilos de IA, una misma responsabilidad humana

Este experimento deja una reflexión clara, y es que hoy en día, con IAs, hacer que una app exista es barato. En minutos puedes tener archivos, pantallas, incluso un flujo completo desplegado. Lo complejo empieza cuando tu objetivo no es simplemente que funcione, sino que sea exactamente lo que tú quieres.

Las dos IAs, de maneras distintas, rellenaron huecos. Si no defines con precisión cómo debe ser la arquitectura, proponen una. Si no delimitas qué significa “visión de platos complejos”, te ofrecen el modelo más a mano. Y si no instrumentas la fidelidad visual, te entregan una interfaz “bastante parecida” y la dan por buena.

Por eso, la IA es el motor de aproximación, pero el desarrollador es el sistema de medida. Y medir no es solo pasar tests unitarios. En productos como FoodCheck también significa comprobar que el despliegue cumple restricciones (GitHub Pages, sin backend), validar integración (tokens, CORS, endpoints, “Failed to fetch”), y tener un criterio tangible para lo subjetivo (qué es “idéntico” en una interfaz).

Si hay que destacar alguna diferencia práctica entre ambos modelos, podría decir que con Codex el trabajo humano se concentra al inicio, definiendo bien tareas, restricciones y arquitectura. Con MiniMax, el esfuerzo se desplaza al final revisando decisiones, detectando supuestos incorrectos y validando que tienes realmente lo que querías.

Ninguno elimina el trabajo del desarrollador; simplemente lo mueve de sitio. Elegir uno u otro no es tanto una cuestión de potencia del modelo como de en qué fase prefieres invertir tu atención. Pero en ambos casos, el resultado final depende menos del modelo que de la claridad con la que el desarrollador define qué cuenta como éxito.

En cualquier caso, quizá la enseñanza más interesante de todas es que cuando tienes un asistente que programa rápido, el trabajo se desplaza. Ya no es tanto escribir código, sino definir con precisión qué cuenta como correcto. Porque, si no lo defines tú, lo definirá la IA… y lo hará a su manera.

De foto a información nutricional: creando una app basada en Inteligencia Artificial

Estefanía Márquez — Wed, 26 Nov 2025 19:37:57 +0000

Registrar lo que comemos es útil, pero aburrido. Abrir una app, buscar “arroz”, comparar marcas, ajustar gramos… ¿Y si hiciéramos una foto y la IA reconociera el plato para darnos una estimación nutricional? Sin cuentas, sin subir nuestros datos a servidores misteriosos.

Así nace FoodCheck, una web app estática desplegada en GitHub Pages que detecta alimentos en fotos, estima porciones y calcula nutrientes usando OpenFoodFacts. La “magia” de visión no va en el navegador ni en un backend tradicional, sino que la delegamos a un Cloudflare Worker que usa Workers AI (modelo LLaVA).

La idea detrás de FoodCheck

El usuario abre la app, selecciona si tiene alguna enfermedad y arrastra una foto de la comida que quiere analizar. La aplicación detecta entonces los alimentos, estima cantidades y muestra la información nutricional. Luego puede ajustar gramos, añadir nuevos alimentos y guardar la comida del día.

Todo se almacena en local, sin servidores externos.

Herramientas

Visual Studio Code
HTML, Tailwind CSS y Javascript
Google Fonts (Montserrat)
OpenFoodFacts (API pública, sin API key)
Cloudflare Workers AI (modelo @cf/llava-hf/llava-1.5-7b-hf)
Despliegue: GitHub Pages (frontend) + Cloudflare Workers (proxy e IA)

Un frontend minimalista

Cuando queremos prototipar una idea rápidamente, a menudo menos es más. En el caso de FoodCheck, el frontend puede ser tan simple como un único archivo index.html. No necesitas frameworks pesados ni configuraciones complejas para empezar a experimentar.

Para conseguir una interfaz simple pero funcional que permita al usuario subir una imagen y obtener resultados de análisis visual, usamos:

Tailwind CSS para estilos rápidos.
Montserrat, una fuente elegante que mejora la estética general.
Un pequeño script que gestiona el flujo de interacción con el backend (en este caso, un Worker de Cloudflare).

Como guía, esta podría ser la estructura de tu index.html:

				
					<!DOCTYPE html>
<html lang="es">

<head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>FoodCheck</title>
    <meta name="description" />
    <link rel="preconnect" href="proxy.php?url=https://fonts.googleapis.com" />
    <link rel="preconnect" href="proxy.php?url=https://fonts.gstatic.com" crossorigin />
    <link href="proxy.php?url=https://fonts.googleapis.com/css2?family=Montserrat:wght@400;500;600;700&display=swap"
        rel="stylesheet" />
    <script src="proxy.php?url=https://cdn.tailwindcss.com?plugins=forms,typography,aspect-ratio"></script>
    <script type="application/json" id="foodcheck-config">
        { "visionEndpoint": "https://TU-WORKER-NAME.tu-cuenta.workers.dev/" }
    </script>
    <style>
        body {
            background: linear-gradient(160deg, #fff6f0 0%, #fffdf8 35%, #ffffff 100%);
            color: #1f2937;
            font-family: "Montserrat", system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", 
                sans-serif;
        }

        <!-- Resto de código -->
    </style>
</head>

<body class="bg-gray-50 flex flex-col items-center p-6">
    <h1 class="text-2xl font-semibold mb-4">FoodCheck</h1>
    <!-- Resto de código -->
</body>

</html>

Qué hay detrás de la foto (el pipeline real)

Cuando el usuario arrastra una foto al frontend de FoodCheck, el proceso real es el que es muestra en el siguiente diagrama:

1. Detección del alimento

El frontend obtiene la URL del Worker desde el bloque de configuración JSON que ya incluimos en el del index.html y que hace de puente entre el navegador y el backend en Cloudflare Workers.

Cuando el usuario añade una imagen, la convertimos en Data URL con FileReader.readAsDataURL (formato data:image/…;base64,…):

				
					function processFile(file) {
  // Leemos como Data URL para poder mostrar y enviar como texto
  const reader = new FileReader();
  reader.onload = (e) => {
    const src = e.target?.result;  // "data:image/...;base64,AAAA..."
    if (!src) return;

    // Guardamos en estado y mostramos la previsualización
    state.image = { src, name: file.name, lastModified: file.lastModified };
    loadImagePreview(src);     // muestra la imagen en la UI
  };
  reader.readAsDataURL(file);
}

Enviamos ese string como JSON al Worker mediante POST, junto con un prompt, y el Worker responde con un JSON que incluye las detecciones. Esas detecciones serán un JSON estructurado, ya que el Worker prepara previamente un prompt en español que le indica al modelo cómo responder, por ejemplo:

				
					{
  "detections": [
    {
      "name": "manzana roja",
      "confidence": 0.92,
      "portion_estimate_grams": 120
    }
  ]
}

Así garantizamos que la respuesta sea estructurada, fácil de interpretar y lista para ser usada por el frontend.

A su vez, la llamada al modelo es directa:

				
					const result = await env.AI.run('@cf/llava-hf/llava-1.5-7b-hf', {
  image: Array.from(imageBytes),
  prompt: systemInstructions,
  max_tokens: 1024
});

Y LLaVA devuelve texto en result.description, de donde hay que extraer el bloque JSON aplicando, por ejemplo:

				
					const cleaned = jsonString.replace(/\\_/g, '_');
const json = JSON.parse(cleaned);
…
return json?.detections ? json : { detections: [] };

El frontend recibe entonces la respuesta limpia con {detections»:[…]}.

2. Estimación de la porción

Antes de usar los resultados, se validan nombres y se normaliza la confianza (0–1). Si el modelo de visión no devuelve una cantidad de porción, se asigna un valor por defecto:

				
					const portionAmount = detection.portionGrams ?? 120;

Además, el usuario puede editar la cantidad y unidad (gramos, ml, pieza, taza) con conversiones predefinidas en el código (por ejemplo, 1 pieza ≈ 80 g, 1 taza ≈ 150 g):

				
					const UNIT_CONVERSIONS = { g: 1, ml: 1, pieza: 80, taza: 150 };

function convertToGrams(amount, unit) {
  const factor = UNIT_CONVERSIONS[(unit || "g").toLowerCase()] ?? 1;
  return (Number(amount) || 0) * factor;
}

3. De nombres a nutrientes

Cada alimento detectado se consulta en OpenFoodFacts para saber su composición nutricional. Se busca por nombre y nos quedamos únicamente con productos que tienen información completa sobre sus nutrientes. Para evitar problemas de CORS y tener un único punto de control, la app no llama a OpenFoodFacts directamente, sino a nuestro Worker (Cloudflare).

Para llamar al Worker y hacer así las consultas, primero construimos una URL con parámetros de interés (texto que escribe el usuario, número de resultados…). Esta URL la llamamos a través del endpoint configurado en el (id foodcheck-config), reutilizando el mismo dominio del Worker de visión:

				
					async function queryOpenFoodFacts(query, limit = 50, options = {}) {
    if (!query || !query.trim()) return [];
    
    const params = new URLSearchParams({
      search_terms: query,
      search_simple: "1",
      json: "1",
      page_size: String(limit),
      lc: "es", 
    });

    const externalSignal = options.signal;
    const controller = externalSignal ? null : new AbortController();
    const signal = externalSignal ?? controller.signal;
    const timeout = externalSignal ? null : setTimeout(() => controller.abort(), 7000);

    try {
      const cfg = JSON.parse(document.getElementById("foodcheck-config").textContent);
      const endpointBase = cfg.visionEndpoint.replace(/\/$/, "");
      
      const proxyUrl = `${endpointBase}/api/nutrition?${params.toString()}`;

      const response = await fetch(proxyUrl, { signal });

      if (!response.ok) throw new Error(`El proxy de nutrición falló: ${response.status}`);
      
      const data = await response.json();
      
      if (!Array.isArray(data.products)) return [];
      return data.products.filter((product) => product?.nutriments);
    } finally {
      if (!externalSignal && timeout) clearTimeout(timeout);
    }
  }

El Worker recibe así los parámetros de búsqueda y hace la petición servidor a servidor a OpenFoodFacts:

				
					async function handleNutritionRequest(request, env) {
  const url = new URL(request.url);
  const params = url.searchParams;

  try {
    const offUrl = `https://world.openfoodfacts.org/cgi/search.pl?${params.toString()}`;
    
    // El worker llama a OFF (de servidor a servidor, sin CORS)
    const response = await fetch(offUrl, {
      headers: {
        'User-Agent': 'FoodCheckApp-Proxy/1.0' }
    });

    const data = await response.json();
    
    // Devolvemos la respuesta de OFF al navegador
    return new Response(JSON.stringify(data), {
      status: 200,
      headers: { ...corsHeaders(), "Content-Type": "application/json" }
    });
  
  } catch (err) {
    return new Response(JSON.stringify({ error: "Error al contactar OpenFoodFacts", details: err.message }), {
      status: 500,
      headers: { ...corsHeaders(), "Content-Type": "application/json" }
    });
  }
}

La respuesta devuelta al navegador es un producto con nutrientes por 100 gramos. La app ajusta los valores nutricionales a la porción estimada previamente calculada siguiendo esta fórmula:

				
					nutriente_por_porción = (nutriente_por_100g * gramos_porción) / 100

3. Visualización y registro local

Los valores obtenidos en el paso anterior se muestran al usuario en un anillo de macronutrientes (kcal y % de energía) y en una tabla de nutrientes. Además, la interfaz muestra también la lista editable de alimentos detectados junto con su cantidad y un mensaje tipo “dietista virtual” con observaciones simples basadas en umbrales fijados:

				
					if (totals.fiber < 12) suggestions.push("Añade verduras, legumbres o fruta para aumentar la fibra.");
if (totals.sodium > 800) suggestions.push("Controla el sodio: limita sal añadida y productos procesados.");
…

El usuario puede guardar cada comida. El registro diario suma automáticamente las comidas y muestra la información nutricional completa, y esto se logra mediante un guardado persistente de datos como el que mostramos aquí:

				
					// Guardado persistente
function persistState() {
  localStorage.setItem("foodcheck:preferences", JSON.stringify({ conditions: state.userConditions }));
  localStorage.setItem("foodcheck:dailyLog", JSON.stringify(state.dailyLog));
}

// Guardar una comida
function saveCurrentMealToHistory() {
  const totals = calculateTotalsFromItems(state.foodItems);
  const entry = { timestamp: Date.now(), items: structuredClone(state.foodItems), totals };
  const day = state.currentDate; // "YYYY-MM-DD"
  const dayEntry = state.dailyLog[day] ?? { items: [], totals: null };
  dayEntry.items.push(entry);
  dayEntry.totals = dayEntry.items.reduce((acc, it) => sumTotals(acc, it.totals), emptyTotals());
  state.dailyLog[day] = dayEntry;
  persistState();
}

Desplegando en GitHub Pages y Cloudflare

El despliegue es doble:

Frontend: repositorio estático en GitHub Pages.
Worker: publicado en Cloudflare con binding env.AI. La URL generada al desplegar es la que usamos en el bloque de Javascript del HTML.

Problemas reales y cómo los resolví

Al principio, intenté conectar FoodCheck con OpenRouter para usar modelos de visión gratuitos. Sobre el papel sonaba bien, pero en la práctica no detectaba alimentos o devolvía respuestas vacías.

Fui intentando solucionar los principales problemas que surgían:

El modelo no veía la imagen, así que hice que le llegaran mensajes multimodales (texto e imagen).
Errores de CORS, por lo que creé un Worker como proxy para gestionarlo.
JSON mal formado, teniendo que implementar un parseo defensivo en el frontend (limpiar el texto, extraer las llaves {} y reintentar JSON.parse()).
Imágenes grandes o HEIC, así que las formateé a JPEG y limité su tamaño (ej.: ).

A pesar de esos ajustes, el sistema seguía sin funcionar. El motivo probable es que los modelos gratuitos de baja prioridad quedaran en cola o expiraran sin respuesta si la red estaba saturada, especialmente sin cuenta de facturación asociada.

Así que busqué otra alternativa que no implicara pagos ni registro sensible, y la encontré justo en Cloudflare Workers AI. Como ya tenía el proyecto desplegado en Workers, probé el modelo LLaVA de Workers AI y funcionó a la primera.

Y es aquí donde Codex juega un papel importante. Lo utilicé como asistente para generar funciones, depurar errores y ajustar prompts. Fue un gran compañero de aprendizaje por su gran precisión y rapidez. Pero con él también aprendí una lección clave, y es que si no defines tú bien la arquitectura de la aplicación, la IA lo va a hacer por ti y es posible que no acierte.

En mi caso, necesitaba una app 100% estática para GitHub Pages y, aunque le di las condiciones exactas, en algún momento propuso crear un servidor Node o usar variables de entorno (.env), lo cual no es posible ahí.

Ahí comprendí que la clave es decidir primero la arquitectura y mantener los prompts coherentes con esa decisión para así usar la IA dentro de ese marco. Por tanto, mejor utiliza la IA para acelerar el trabajo, no para que decida por ti.

Reflexión final

FoodCheck no pretende sustituir a un dietista, pero demuestra algo importante: con un poco de código y una IA bien usada, podemos crear herramientas útiles, privadas y educativas.

Por tanto, el futuro de la IA aplicada a la salud quizás no esté en los grandes servidores, sino en las manos de los desarrolladores curiosos.

Construí una app de Barranquismo sin escribir código: mi experiencia creando una PWA con IA

Jose Ramon García — Tue, 28 Oct 2025 22:28:02 +0000

Introducción

Como muchos amantes de la montaña, me gustaría la posibilidad de tener una página minimalista, donde encontrar la información de los barrancos de manera sencilla y que me permitiera consultar la los tracks cuando no tuviera cobertura en lugar de saltar entre diez webs para encontrar información fiable de un barranco, además, Wikiloc me daba el GPS, Descente-Canyon los datos técnicos, pero nada estaba unificado y, sobre todo, nada funcionaba bien sin cobertura en mitad de la nada.

Así que decidí construirla yo mismo, aquí tienes el enlace al resultado: https://saturdaysai.github.io/barranquismo/

Quería una web sencilla: filtros, mapas y que funciona 100% offline. Pero esta vez, decidí no hacerlo solo. Y no solo eso, sino que no escribiría una línea de código. Asi que busqué dos compañeros que lo hicieran por mi:

ChatGPT, como consultor técnico y de UX.
Codex (integrado en Visual Studio Code), como programador ejecutor.

Mi objetivo: demostrar que, con buena planificación y prompts precisos, una sola persona puede construir una aplicación funcional, desde cero, usando solo IA.

Fase 1. Planificación y elección del stack

Antes de escribir una línea de código, necesitaba un plan sólido. Mi primera interacción fue con ChatGPT, para definir la arquitectura tecnológica.

Prompt clave a ChatGPT:
“Quiero construir una web para un inventario de barrancos. Los usuarios deben poder filtrar por dificultad y ver mapas. Lo más importante: debe funcionar offline. No quiero usar backend y planeo desplegarla gratis en GitHub Pages. ¿Qué stack tecnológico me recomiendas y cómo debería estructurar el proyecto?”

La IA recomendó Vite + React por su rapidez y facilidad para configurar Service Workers, esenciales para el modo offline. Con eso, ya tenía la brújula técnica del proyecto.

Fase 2. Inicialización del proyecto en Visual Studio Code

Abrí una nueva carpeta (canyoningApp) y, desde Visual Studio Code, lancé Codex en modo agente. Seleccioné la IA GPT-5 Codex Preview y le pedí iniciar el proyecto paso a paso. Introduciendo el prompt que me había facilitado ChatGPT modificando un poco el formato para que lo adaptada a mis necesitades, incorporando paradas y que hubiera retroalimentación durante el proceso.

Fase 3. Diseño de la estructura base

El siguiente paso fue definir la estructura de navegación antes de cargar datos o diseñar la interfaz.

Prompt de ChatGPT a Codex:

Desarrollaremos una web app estática tipo PWA con fichas descriptivas de cada barranco, material necesario y enlaces externos (Wikiloc para aproximación y retorno).Quiero que me ayudes paso a paso con este flujo de trabajo estructurado:

Aterriza la idea (concepto): define el propósito, las funcionalidades clave, y el stack tecnológico (React + Vite o JS puro).

Planifica la arquitectura: estructura de carpetas, uso de localStorage en lugar de base de datos, sin autenticación, todo client-side, apto para despliegue en GitHub Pages.

Construye el proyecto: crea el código base con documentación en comentarios y guíame fase por fase (estructura, página principal, fichas, mapa, persistencia local, filtros, diseño, PWA).

Documenta el proceso: cada paso debe incluir explicaciones breves, código comentado, y notas para poder luego redactar un artículo/tutorial.

Prepara el despliegue: muestra cómo configurar vite.config.ts o index.html para GitHub Pages.Condiciones:

Toda la persistencia debe hacerse con localStorage.

No usar ningún backend ni login.

Código modular, limpio y comentado.

Usa inglés en el código, pero español en las explicaciones.

Pide validación antes de avanzar a cada fase.

La app debe ser responsive y ligera. Empieza con la fase 1 (concepto) y espérame antes de pasar a la siguiente fase. Cuando te diga ‘sigue’, pasas a la siguiente.

Genera la estructura de componentes de React (por carpetas) y el código de para gestionar esta navegación de 5 pestañas y la ruta de detalle anidada»

A continuación me solicitó varias preguntas en relación a lo que había entendido (codex) para seguir, la con la ejecución:

En cada una de las respuestas que me iba dando le consultaba a ChatGPT si Codex lo estaba haciendo correctamente, en caso afirmativo proseguía con la ejecución:

El resultado fue un esqueleto modular de componentes con rutas, páginas y una estructura de carpetas profesional. Codex se encargó de crear los archivos iniciales, dependencias y configuración del proyecto automáticamente.

Ahora sí, Codex empezó a trabajar, generando carpetas y archivos, durante el proceso va preguntado si quieres ejecutar algunas instrucciones de sistema y de depuración, a lo que le dices que si para que hagas las modificaciones que tiene que hacer.

Tras unos minutos, Codex generó toda la estructura de carpetas, dependencias y scripts.

Lo mejor de todo es que el proyecto compilaba sin ningún error de compilación ni de ejecución, simplemente increíble… Una vez finalizado probé en arrancar el servidor en local. Pero no sabía cómo levantar la web app así que le pregunté:

Ahora hay varias opciones: o lo ejecutas desde una consola externa o en mi caso use la que ya está instalada en VSC en la pestaña intermedia terminal:

Una vez lanzada la web app, intento conectarme al navegador para comprobar si funciona:

La página funcionaba. ¡En menos de 30 min ya tenía una página lista!

Fase 4. Subir la app a GitHub Pages

La idea inicial era aprovechar el servicio que dispone GitHub para alojar la web app, por lo que pedí ayuda a codex a como realizarlo correctamente:

Antes de empezar si no tenemos cuenta de GitHub, se crea una, es totalmente gratuita. Una vez creada, creamos el repositorio, es muy importante que se llame como vuestra carpeta de proyecto ya que si no las dependencias no funcionarán correctamente.



Una vez creado, subimos el repositorio con las siguientes instrucciones desde la carpeta raíz, podemos hacerlo desde una consola o desde la terminal:

Si no tenemos Git habrá que instalarlo, lo puedes descargar aquí. Una vez instalado:

git init // Inicializa un proyecto git en local

git add . // Agrega archivos al repositorio

git commit -m "Primer commit"       // Guarda los cambios en tu repositorio local

git remote add origin https://github.com/TU_USUARIO/NOMBRE_REPOSITORIO.git

// Vincula tu repositorio con GitHub.

git push -u origin main // Sube tus cambios a GitHub

Ahora ya tenemos subido el mismo repositorio que tenemos en local con GitHub, ahora cada cambio que queramos hacer deberemos empezar los pasos desde el 2 y muy importante poner a los commits nombres de las modificaciones que vayamos haciendo, así luego es más fácil volver a un estado anterior sabiendo que modificaciones hicimos en ese momento.

Una vez ya tenemos el repositorio le preguntamos a codex como subirlo a GitHub pages correctamente:

seguimos las instrucciones:

y accedemos a la web app desde GitHub:

Como podemos comprobar, la versión inicial es funcional pero faltan los datos en formato JSON y mejorar la estética.

Fase 5 : Recopilación de datos e importar a JSON

Recopilar datos de cada uno de los barrancos uno a uno es muy tedioso, además corres el riesgo de equivocarte al extrapolar los datos, por lo que le pregunto a Codex si me puede ayudar:

Su respuesta es un script

Vamos un paso más allá, le decimos que genere el mismo un script y que él mismo lo ejecute y que además lo guarde en el el archivo JSON con los barrancos que pusimos ficticios.

El mayor desafío era la información. Los datos estaban en fuentes abiertas, en diferentes formatos y cada página tenía una descripción distinta de cada atributo y no mantienen una coherencia por lo que los datos que obtuve estaban totalmente desestructurados. Necesitaba un pipeline de limpieza.

Fase 6. Normalización de datos con IA

Como datos de los barrancos provenían de distintas fuentes (Descente-Canyon, Wikiloc, etc.), y estaban desordenados y con distintos formatos. Necesitaba un script en Node.js para limpiarlos y unificarlos.

Prompt a Codex:
“Tengo varios JSON con datos de barrancos. Necesito un script que lea todos, normalice los nombres, extraiga coordenadas y unifique los niveles de dificultad. Exporta un único dataset.json final.”

Codex generó un script de limpieza automatizado. El resultado: un archivo dataset.json consolidado, que serviría como base de datos local de la aplicación.

Fase 7. Creación de la interfaz React

Con el dataset listo, era momento de visualizar los datos. En lugar de escribir componentes manualmente, los pedí directamente a Codex.

Prompt 1:
“Crea un componente que importe 'dataset.json'. Debe incluir buscador y filtros dinámicos (por dificultad y zona). Mapea los resultados en tarjetas (‘BarrancoCard’) enlazadas a una vista de detalle.”

Prompt 2:
“Crea un componente ‘FichaDetalle’. Muestra datos del barranco: rápel máximo, tiempos, coordenadas y enlaces.”

Codex generó la estructura React completa y los componentes necesarios. Incluso añadió un mapa interactivo con Leaflet tras otro prompt específico.

Fase 8. Añadir La «memoria» offline

La app necesitaba “recordar” datos del usuario, como la checklist y valoraciones.

Prompt a Codex:
“En mi app, los usuarios deben valorar un barranco con estrellas y añadirlo a una ‘Checklist’. Estos datos deben persistir incluso sin conexión. Usa localStorage.”

Codex implementó la lógica de almacenamiento local y la recuperación automática. Luego configuramos el Service Worker para hacer la app totalmente funcional offline: ya era una PWA instalable y usable sin cobertura.

Fase 9. Mejora de diseño UX/UI con ChatGPT

La funcionalidad estaba lista, pero la interfaz necesitaba un toque profesional. Volví a ChatGPT, esta vez como diseñador UX especializado en entornos outdoor.

Prompt clave:
“Estoy diseñando esta app para usarla en montaña, bajo sol intenso y con reflejos. Dame recomendaciones de UX/UI y un prompt detallado para Codex como si fuera un diseñador profesional.”

# CONTEXTO DEL PROYECTO

Estoy desarrollando una PWA en React + Vite llamada “Barranquismo”, pensada para usarse en montaña y entornos naturales.

Los usuarios la consultarán en condiciones reales de campo: con luz solar intensa, reflejos, guantes, y conexión limitada.

La app muestra fichas de barrancos con dificultad, material, tiempos y enlaces a Wikiloc.

No tiene backend: todo funciona en el cliente (localStorage, JSON local) y se desplegará en GitHub Pages.

# OBJETIVO

Quiero que actúes como un **diseñador profesional de UX/UI especializado en entornos outdoor, accesibilidad y diseño funcional**.

Tu tarea es mejorar el diseño visual y la experiencia de uso de la aplicación **para que sea bonita, legible y profesional**, sin perder simplicidad ni rendimiento.

Dame sugerencias detalladas de diseño y, si es posible, fragmentos de código (JSX, CSS o Tailwind) listos para implementar.

# QUÉ QUIERO CONSEGUIR

– Una interfaz **bonita y coherente**, digna de un producto profesional.

– **Alta legibilidad bajo el sol**: textos grandes, fuentes claras y contraste fuerte.

– **Componentes visualmente atractivos** pero sencillos de renderizar en React (sin dependencias pesadas).

– **Jerarquía visual clara** (colores, tamaños y espacios bien definidos).

– **Estilo outdoor**, natural y moderno (inspirado en apps como Komoot, AllTrails o Wikiloc).

– **Interacción táctil cómoda** (botones amplios, feedback visual inmediato).

– **Adaptación móvil total** (mobile-first con breakpoints a tablet).

– Que respete buenas prácticas de **accesibilidad (WCAG 2.1)**.

– Que proponga una **paleta de colores y tipografía profesional**, ideal para sol directo y contextos naturales.

# PUNTOS CLAVE QUE DEBES CUBRIR

1. **Tipografía**

– Usa fuentes sans-serif legibles (ej. Inter, Poppins, Nunito, Roboto Flex).

– Tamaños: mínimo 16–18px para texto, 22–28px para títulos.

– Buen espaciado (`letter-spacing`, `line-height`) para lectura bajo reflejos.

2. **Colores y contraste**

– Contraste alto (WCAG AAA) entre fondo y texto.

– Propón una paleta profesional inspirada en la naturaleza (azules, beige, verdes oscuros, grises cálidos).

– Incluye un modo alto contraste o “modo exterior”.

3. **Componentes y botones**

– Áreas táctiles grandes (mínimo 44x44px).

– Botones redondeados con sombra suave o borde definido.

– Feedback visual al pulsar (cambio de color, opacidad o elevación).

– Mantén consistencia en iconos, sombras y radios.

4. **Diseño visual**

– Minimalismo funcional: sin recargar, pero agradable visualmente.

– Distribución clara: encabezado fijo, lista de barrancos con tarjetas (cards) bien separadas y detalles accesibles.

– Uso equilibrado de color para jerarquía: títulos, botones primarios, acciones secundarias.

5. **Estilo global**

– Insp

iración en Material Design y Fluent UI, adaptado al uso outdoor.

– Animaciones sutiles (fade, scale) solo si no afectan al rendimiento.

– Bordes suaves, sombras naturales, espacios amplios.

– Consistencia entre Home, Detail y Checklist.

6. **PWA y rendimiento**

– Fuentes y colores precargados.

– No uses imágenes pesadas, usa SVG o íconos vectoriales.

– Optimiza para modo offline (mínimo CSS y assets).

7. **Accesibilidad**

– Contraste mínimo 4.5:1 en todos los textos.

– Colores accesibles para daltónicos (usa color+forma).

– Texto alternativo en iconos, roles ARIA en botones.

# FORMATO DE RESPUESTA ESPERADO

– Lista de recomendaciones de UX/UI ordenadas por prioridad (alta, media, baja).

– Propuesta de **paleta de colores y tipografía** profesional.

– Ejemplos concretos de CSS o Tailwind para implementar.

– Justificación breve de cada sugerencia (por qué mejora la visibilidad, estética o usabilidad).

– Mockup textual o wireframe (opcional) para la estructura ideal de la pantalla principal.

# TECNOLOGÍAS

– React + Vite

– Tailwind o CSS Modules

– LocalStorage

– GitHub Pages (PWA estática)

# INSTRUCCIÓN FINAL

Actúa como un diseñador UX/UI profesional.

No des teoría: **dame propuestas listas para aplicar** con código o estilos concretos.

Equilibra **belleza, usabilidad y funcionalidad outdoor**.

El resultado debe parecer hecho por un diseñador experto, pero optimizado para React y PWA ligeras.

El resultado fue una guía completa: tipografías legibles (Inter, Poppins), alto contraste, botones grandes, jerarquía visual clara y estilo outdoor inspirado en Komoot y AllTrails. Codex aplicó las mejoras automáticamente y la interfaz ganó claridad, accesibilidad y coherencia.

Fase 10. Despliegue final y pruebas

Una vez pedido esos cambios a Codex, modificó lo que consideró necesario, después de unos minutos (es fascinante ver como va modificando a tiempo real el código) ya estaba lista una versión como ya que necesitaba:

volví a visualizar la página ejecutando en consola:

entro en el navegador y…

La página que había creado ya estaba lista y era funcional. Tras verificar los cambios, ejecuté un nuevo git push y esperé la actualización de GitHub Pages. A veces los cambios tardan en reflejarse por el almacenamiento en caché o localStorage, pero tras limpiar el navegador, la nueva versión funcionaba perfectamente.

Ya tenía una app completa, funcional, ligera y 100% generada con IA.

Conclusiones y aprendizajes

Desarrollar esta aplicación fue mucho más que programar: fue aprender a comunicarme con una IA. El rol del desarrollador cambia: ya no se trata de escribir código, sino de formular problemas, guiar al sistema y validar resultados.

La precisión de los prompts lo es todo. Un buen contexto genera código limpio y funcional.
La validación humana sigue siendo esencial. La IA propone, pero tú decides qué aceptar o ajustar.
El flujo de trabajo híbrido (ChatGPT + Codex) es tremendamente eficiente para proyectos personales o prototipos.
GitHub Pages y PWA son la pareja perfecta para proyectos sin backend.

Recursos y enlaces

Repositorio GitHub: https://github.com/SaturdaysAI/barranquismo
Framework: React + Vite
IA utilizadas: ChatGPT (asistente técnico y UX) y Codex (generación de código)
Librerías clave: Leaflet, Workbox, TailwindCSS
Despliegue: GitHub Pages (PWA estática)
Web: https://saturdaysai.github.io/barranquismo/

Sobre el autor

José Ramón García
Estudiante de Ingeniería Informática, apasionado por la tecnología aplicada a la naturaleza. Combina su experiencia profesional en la industria alimentaria con proyectos de software y apps outdoor. Explora cómo www.saturdays.ai utiliza la inteligencia artificial para potenciar la creatividad y la productividad humana en entornos reales.

Crea una web wiki de tu juego o contenido favorito siguiendo estos pasos (y con IA)

Adrian Algar — Wed, 22 Oct 2025 10:22:22 +0000

En este artículo encontrarás una guía clara y accionable para construir una wiki moderna con búsqueda compartible, galerías reutilizables, páginas de detalle, mapa interactivo y un minijuego de trivia. Todo con Vite + React Router y un empujón de IA.

A continuación te mostraré cómo hice la mía basada en uno de mis videojuegos favoritos: Hollow Knight .

Puedes acceder a la Wiki desde los siguientes enlaces para visualizar el resultado y todo el contenido AL COMPLETO antes de la explicación:

De la Idea al Sitio Vivo

Crear una wiki es como montar un museo temático: tú eliges la colección (tu tema), diseñas el recorrido (la navegación) y curas cada pieza (las páginas de detalle).

¿La buena noticia?

Hoy puedes construirla rápido con Vite + React, publicarla gratis en GitHub Pages y enriquecerla con funciones “sorpresa” como mapas interactivos, búsqueda compartible por URL y un minijuego de trivia para aprender jugando.

La guía técnica que tienes a mano ya te trae el esqueleto con rutas, estilos, carga de imágenes y despliegue, de modo que puedes replicar el proyecto desde cero sin perderte en la configuración.

¿Por qué una wiki con ayuda de la IA?

La IA no “escribe por ti”; te acelera y mantiene la calidad cuando el contenido crece. Estas son razones y casos de uso prácticos:

Arrancas más rápido: La IA te sugiere un índice inicial y te ayuda a ordenar ideas. Pasas de “tengo un montón de notas” a “ya tengo una estructura”.
Escribes con más fluidez: Convierte apuntes sueltos en textos claros y con un mismo tono. Tú decides el estilo; la IA te ayuda a mantenerlo.
Todo queda más uniforme: Propone títulos, slugs y resúmenes cortos para que las listas se vean limpias y fáciles de recorrer.
Menos errores, más cuidado: Señala enlaces rotos, faltas y alt‑texts que faltan en imágenes. Es como un revisor amable que no se cansa.
Te da ideas nuevas: Sugiere preguntas para la trivia, sinónimos para la búsqueda y pequeñas mejoras que no habías pensado.
Tú sigues al mando: La IA acelera, pero no sustituye tu criterio. Tú eliges qué entra, qué se modifica y cómo se cuenta la historia.

En resumen: la IA no hace la wiki por ti; hace que sea más fácil, más rápida y más agradable de construir.

Visión rápida del proyecto

Producto: sitio con dos vistas principales
- Wiki: índice, galerías por secciones y páginas de detalle.
- Trivia: partida configurable (categoría/dificultad/cantidad) con resultados.
Datos: ficheros JSON versionados en el repositorio.
Interfaz: componentes reutilizables y estilos coherentes.
Navegación: rutas claras para portada, secciones, detalle, mapa y trivia.
Publicación: preparado para desplegar fácilmente en GitHub Pages.
IA: apoyo para estructurar, redactar y revisar el contenido.

Una vez tengamos clara la idea podemos empezar con la creación de la estructura de carpetas. La IA puede ser una parte fundamental en el siguiente paso, ya que te va a ayudar a estructurar-lo de una forma eficiente:

Arranque del Proyecto

Lo primero que necesitamos es tener la base lista para iniciar en local:

Instalar dependencias: npm install
Arrancar en dev: npm run dev
Build de producción: npm run build
Previsualizar el build: npm run preview

Estructura mínima que usamos:

src/main.tsx: monta la app y aplica index.css.

src/App.tsx: define el enrutado con React Router.

Usamos BrowserRouter basename={import.meta.env.BASE_URL} para que funcione en GitHub Pages bajo /repo.

src/index.css: estilos globales, variables CSS y layouts (grid/galería, detail, hero, navbar…). A continuación un ejemplo pequeño del CSS, (lo encontrarás completo en mi repositorio de GitHub):

Routing y Páginas Principales

Ruta	Página (componente)	Función
`/`	`Home.tsx`	Portada con vídeo de fondo y buscador rápido. Entrada al resto del sitio.
`/wiki`	`WikiIndex.tsx`	Índice global; búsqueda “linkeable” (estado tomado de la URL, p. ej. `?q=`).
`/wiki/bosses`	`BossesPage.tsx`	Lista de jefes (cards con estrellas).
`/wiki/warrior-dreams`	`WarriorDreamsPage.tsx`	Lista del grupo “warrior-dreams”.
`/wiki/variants`	`VariantsPage.tsx`	Lista de variantes.
`/wiki/charms`	`CharmsPage.tsx`	Lista de charms (muestras).
`/wiki/items`	`ItemsPage.tsx`	Lista de ítems (categoría visible en la tarjeta).
`/wiki/:group/:slug`	`WikiDetail.tsx`	Detalle por grupo y slug (card + overview + chips).
`/map`	`MapPage.tsx`	Mapa interactivo con toolbar y panel de detalle.
`/trivia`	`TriviaStart.tsx`	Pantalla inicial de trivia (configuración/cantidad).
`/trivia/results`	`TriviaResults.tsx`	Resultados/resumen de la trivia.
`*`	`NotFound.tsx`	404.

Piezas Transversales

NavBar.tsx: HOME/WIKI/TRIVIA con NavLink.

SearchBar.tsx: input que, al enviar, navega a /wiki?search=… (la URL es la “fuente de verdad”).

Footer.tsx: info que se mantiene en toda la wiki.

Página: HOME

Pantalla de presentación con fondo animado a pantalla completa, logo, texto, barra de búsqueda y dos CTAs hacia la wiki y la trivia.

Índice de la wiki : WIKINDEX

El buscador de Home te lleva a /wiki?search=TERM. El índice lee ese parámetro con useSearchParams, normaliza (minúsculas + sin diacríticos) y filtra por title, summary o slug en varios datasets. Ventaja: la búsqueda va en la URL y se puede compartir o refrescar sin perder estado.

Páginas de sección (listas)

Todas comparten patrón: ponen un fondo específico (fondoX) en –page-bg, y renderizan con sus datos e imágenes:

Bosses

Listado de los bosses del juego calificados con estrellas de dificultad.

Warrior Dreams

Listado de bosses oníricos calificados con estrellas de dificultad.

Variants

Listado de variantes de bosses calificados con estrellas de dificultad.

Charms

Listado de amuletos calificados por cantidad de muescas que ocupa.

Items

Listado de objetos calificados por diferentes funcionalidades en el juego.

Interactive Map

Mapa interactivo con etiquetas desplegables por zona.

El mapa aplica un fondo específico a la página mientras está abierto.

La imagen principal se escala al viewport y puedes arrastrarla para moverte; un tope invisible impide salirte de los bordes.

Las áreas se renderizan como etiquetas clicables con colores propios.

La búsqueda filtra esas etiquetas y, al pulsar Enter, centra la primera coincidencia y abre su detalle (también puedes centrar con ?center=slug).

El panel de detalle muestra imagen, resumen y lore de la zona y se puede cerrar para volver a explorar.

Galerías por categoría (reutilizables)

Gallery.tsx: componente de galería reutilizable que lista tarjetas y navega al detalle.

Props: title, backTo?, items[{ slug, title, img?, summary?, difficulty?, notches? }], basePath, assetsGlob, resolveBy: "slug"|"filename", showStars?.
Imagen: resuelve la URL buscando en assetsGlob por slug (jpg/png/webp) o por filename; muestra fallback con el título si no hay imagen.
Card: a ${basePath}/${slug}; figure con backgroundImage, figcaption con título.
Meta: si showStars ⇒ estrellas (1–5) usando difficulty; si no ⇒ muescas usando notches.
Accesibilidad/maquetado: ul.gallery-grid con aria-label; estrellas y muescas con aria-label/title; clases gallery-* para estilos.

Página de detalle: WIKIDETAIL

En /wiki/:group/:slug, WikiDetail.tsx lee parámetros, selecciona dataset e imagen y renderiza un layout de dos columnas: imagen grande a la izquierda; a la derecha DETAILS (p. ej. dificultad→estrellas, efectos, drops…) y más información dependiendo de la sección. Incluye un patrón de tabla que mapea cada grupo a su dataset y su mapa de imágenes.

Imágenes automáticas por slug (sin imports manuales)

Con import.meta.glob creas mapas {ruta → url} por carpeta y resuelves por slug y extensión (.jpg/.png/.webp). Funciona en dev y en build (Vite copia assets con hash).

Trivia: aprender jugando

En TriviaStart configuras categoría/dificultad/cantidad, se crea un mazo barajado (Fisher–Yates) y se juega en la misma vista; al terminar, TriviaResults lee la puntuación desde sessionStorage. Actualmente se barajan las preguntas; el barajado de respuestas es opcional y fácil de añadir después.

Codigo del Fisher-Yates:

Página results con mensaje personalizado dependiendo el resultado:

Pequeña parte del código para mostrar el resultado:

Despliegue en GitHub Pages

vite.config.ts (base en subcarpeta):

Workflow .github/workflows/deploy.yml (build + deploy con Actions) y Pages → Source: GitHub Actions. Para SPA, copia index.html a 404.html tras el build para evitar 404 en rutas internas. Incluye también el flujo de trabajo recomendado y una checklist (base correcto, basename en router, globs a assets, buscador responsive).

Consejos finales y cómo entra la IA

Pide a la IA el índice inicial (secciones, taxonomías, campos) y que señale huecos;
Genera slugs kebab-case y nombres de archivo de imagen a partir de títulos;
Redacta resúmenes de 120–160 caracteres para tarjetas y 2–3 párrafos para el detalle;
Crea lotes de preguntas (1 correcta + 3 distractores) y pega el JSON en questions.json. El barajado, la carga de imágenes y la búsqueda por URL ya están resueltos en el código.
CODEX es una herramienta muy útil para el desarrollo de la wiki, y este artículo te enseña a obtenerla y usarla en VS Code.

Siguiendo este esquema y mi repositorio con el proyecto completo, tendrás una wiki que se lee bien, se comparte fácil y apetece explorar.

Añade tus datasets, nombra las imágenes por slug, publica con un push y listo.

Si te animas, amplía categorías, añade relaciones entre fichas o más minijuegos: la arquitectura está pensada para crecer.

Del Caos al Control: La Transformación de Carlos y su Fábrica Inteligente

Jose Ramon García — Mon, 13 Oct 2025 11:12:44 +0000

Carlos Méndez llevaba más de veinte años al frente de FríoMon, una empresa familiar de ultracongelados situada en el cinturón industrial de Barcelona. Había heredado el negocio de su padre, un hombre que creía que el trabajo duro, la constancia y la intuición eran suficientes para mantener una fábrica en marcha. Durante mucho tiempo, eso bastó. Pero los tiempos habían cambiado.

Las líneas de producción seguían funcionando con la misma maquinaria de hace más de una década. Cada día salían cientos de cajas de canelones, albóndigas y croquetas congeladas rumbo a supermercados de toda España. Sin embargo, los errores eran cada vez más costosos: lotes mal etiquetados, productos que se almacenaban fuera de orden, y un sistema de control de calidad manual que dependía de los ojos cansados de los operarios después de largas jornadas viendo pasar el producto por una cinta.

Carlos, a sus 47 años, sentía que el negocio se le escapaba de las manos. No era falta de esfuerzo, sino de visión. “No puedo seguir apagando fuegos todos los días”, se repetía frente a la pantalla de su despacho, observando gráficos que no entendía del todo.

El punto de inflexión

Un día, durante una feria tecnológica en Barcelona, Carlos se detuvo ante un pequeño stand donde un grupo de jóvenes mostraba una cámara conectada a un ordenador. En la pantalla, los asistentes veían cómo el sistema detectaba defectos en frutas y verduras en tiempo real.
—Esto es visión artificial —le explicó una de las ingenieras—. Analiza imágenes en milisegundos y detecta imperfecciones que el ojo humano podría pasar por alto.

Carlos se quedó observando, fascinado. Esa misma tarde, buscó información sobre cómo aplicar algo así en su planta. Descubrió que no era solo una cámara: era inteligencia artificial, aprendizaje automático, algoritmos capaces de ver, predecir y tomar decisiones. Aquella noche no durmió.
Por primera vez en mucho tiempo, sintió que la solución a sus problemas podía estar delante de él.

El inicio del cambio

Decidió dar el salto. No tenía conocimientos técnicos, pero sí la determinación de aprender. Contrató a una joven ingeniera de datos, Lucía, que venía de trabajar en un proyecto piloto de Saturdays.AI. “No necesito a alguien que me venda promesas -le dijo Carlos-. Necesito a alguien que entienda mi fábrica y me ayude a transformarla”.
Lucía aceptó el reto. Durante las primeras semanas, recorrió la planta con una Tablet, grabando vídeos de las cintas transportadoras, los túneles de congelación y las zonas de envasado.

“Tu problema no es la falta de trabajo —le dijo un día—. Es la falta de datos. Todo lo que aquí ocurre queda en el aire: quién hizo qué, cuándo se congeló cada lote, cuántos segundos estuvo a cierta temperatura… la IA no puede ayudarte si no la alimentas con información real.”

Así renació Carlos, con un nuevo enfoque digital.

Visión artificial y control de calidad

El primer módulo fue una cámara de alta resolución conectada a un sistema de visión artificial. Cada producto que pasaba por la cinta era fotografiado y analizado en milisegundos. Si la croqueta tenía una forma irregular, si el empaquetado estaba dañado o si el código QR no coincidía con el lote, el sistema enviará una alerta y aparta el producto automáticamente.

En cuestión de semanas, los informes mostraban una reducción del 60 % en errores de etiquetado. Los operarios, que al principio miraban la cámara con desconfianza, empezaron a verla como una aliada. “Ahora sabemos qué falla y cuándo”, decían.

Carlos se emocionaba cada vez que veía el panel de control en el monitor de la sala de supervisión. En lugar de hojas sueltas y notas escritas a mano, tenía un dashboard que mostraba estadísticas en tiempo real. Por primera vez, su fábrica hablaba.

Del almacén al cerebro predictivo

El siguiente paso fue automatizar el almacén. Lucía propuso integrar sensores de visión y códigos OCR para leer automáticamente las etiquetas de los palets que llegaban y salían.
Cada vez que un camión descargaba materia prima, la cámara reconocía el lote, la fecha de caducidad y el proveedor, comparándolo con el albarán digital. Si había alguna discrepancia, el sistema avisaba antes de que el producto entrara en cámara.

El resultado fue inmediato: se eliminaron los errores humanos y se implantó un control FEFO (First Expired, First Out) casi perfecto. Además, el sistema avisaba cuando un lote estaba próximo a su vencimiento, priorizando su uso o venta.
“Ahora el almacén piensa antes que nosotros”, decía con una sonrisa uno de los encargados.

Pero lo más revolucionario estaba por venir. Lucía y su equipo crearon un modelo de IA predictiva que analizaba patrones de consumo, tiempos de entrega y condiciones ambientales para ajustar la producción y el almacenamiento.
El sistema podía sugerir, por ejemplo, que se redujera la producción de ciertos productos en verano o que se adelantara el envasado de otros antes de un puente festivo.
Era como si la fábrica hubiera adquirido un sexto sentido.

La resistencia y la adaptación

No todo fue sencillo. Algunos trabajadores temían que las máquinas los sustituyeran. Carlos reunió a todos en la sala de juntas.
—Nadie va a perder su trabajo por esto —les dijo—. Pero sí vamos a cambiar la forma de trabajar. La IA no viene a reemplazarnos, sino a ayudarnos a hacerlo mejor.

A partir de ese día, se organizaron sesiones formativas. Los operarios aprendieron a interpretar los indicadores de la IA, a entender los mapas de calor que mostraban los puntos de fallo en la línea, y a proponer mejoras.
Incluso algunos veteranos, que nunca habían tocado un ordenador, empezaron a usar tablets para registrar incidencias.

El impacto humano y empresarial

En menos de un año, FríoMon se había convertido en un referente de innovación industrial. Las mermas se redujeron un 30 %, las reclamaciones de clientes un 40 % y los beneficios aumentaron un 18 %.
Pero más allá de las cifras, lo que cambió fue la cultura.

Carlos ya no era el empresario que revisaba papeles al final del día. Se había convertido en un líder digital. Entendió que la inteligencia artificial no era magia ni amenaza: era una herramienta de conocimiento.
“Antes tomábamos decisiones con los ojos cerrados —confesó en una entrevista para una revista del sector—. Ahora los tenemos bien abiertos, y los de la IA también.”

Lucía fue ascendida a directora de innovación. Juntos comenzaron a planificar una segunda fase del proyecto: integrar sensores IoT en los camiones refrigerados para supervisar la temperatura y las rutas en tiempo real. La IA podría detectar retrasos o fallos de refrigeración y alertar antes de que el producto se echara a perder.

Epílogo: el legado de una visión

Un año después, Carlos volvió a la feria tecnológica donde todo empezó. Pasó por el mismo stand, ahora más grande, lleno de pantallas y drones.
—Gracias a esto —le dijo al expositor sonriendo—, hoy tengo una fábrica que ve, piensa y aprende.

Mientras se alejaba, pensó en su padre, en las libretas de notas y los relojes de pulsera. Sonrió. “No hemos perdido la esencia —se dijo—. Solo le hemos dado una mente nueva. ”Desde entonces, FríoMon no solo produce alimentos congelados: produce conocimiento, eficiencia y futuro. Y Carlos, el empresario que un día temió perder el control, se convirtió en un pionero de la inteligencia artificial en la industria alimentaria.

El caos había quedado atrás.
Ahora todo funcionaba con la precisión del aprendizaje automático y el corazón humano que lo había hecho posible.

Carlos no es un caso aislado: representa el futuro de la industria que aprende, se adapta y evoluciona con la ayuda de la IA. Si tú también trabajas en una empresa y quieres liderar ese cambio, únete a Saturdays.AI.

El futuro inteligente empieza contigo.

Nutrición en la era digital: cómo la IA está transformando la práctica clínica

Estefanía Márquez — Wed, 08 Oct 2025 10:22:25 +0000

Juan está ingresado en el hospital y le sirven su comida. El personal sanitario pasa un smartphone por encima de su bandeja y, en segundos, una aplicación identifica y cuantifica los alimentos que contiene, estimando también sus nutrientes. Cuando termina de comer, el dispositivo vuelve a analizar la bandeja para determinar lo que realmente ha ingerido y evaluar posibles riesgos nutricionales.

¿Puede una máquina ayudarnos a comprender mejor cómo nos alimentamos y a detectar problemas de nutrición con mayor precisión? La inteligencia artificial (IA) está respondiendo de forma sorprendente a esta pregunta. Estas tecnologías se aplican ya en centros sanitarios y en laboratorios para analizar la dieta de una forma más exacta, diseñar tratamientos ajustados a cada persona y apoyar la investigación de enfermedades relacionadas con la alimentación.

Desde algoritmos que procesan miles de datos hasta dispositivos capaces de monitorizar en tiempo real lo que come un paciente, la IA está abriendo la puerta a una nutrición más personalizada y efectiva. En este artículo se verán algunos de los ámbitos en los que la IA está cambiando la práctica clínica y científica.

Cómo la IA puede ayudar a medir lo que comemos

Conocer de manera precisa qué y cuánto comemos es uno de los grandes retos en nutrición. Si los métodos que existían hasta ahora podían dar lugar a errores ya que dependían de la sinceridad y de la memoria de las personas, la IA ya es capaz de hacer unas estimaciones más exactas.

Gracias a la visión por computador, una simple fotografía de un plato puede bastar para identificar los alimentos que contiene. A través de los algoritmos de deep learning, se puede incluso estimar el tamaño de las porciones y calcular los nutrientes presentes.

En algunos hospitales ya se utilizan sistemas que comparan la bandeja de un paciente hospitalizado antes y después de comer, permitiendo calcular automáticamente cuánto ha ingerido. Además, hay tecnologías que utilizan sensores acústicos o de movimiento mandibular para monitorizar cuándo y cuánto come un paciente.

Todo esto se traduce en datos más objetivos y fiables para los profesionales de la nutrición, que pueden entonces diseñar planes dietéticos más personalizados según las necesidades reales de cada paciente.

IA en prevención de enfermedades y riesgos nutricionales

Nuestra alimentación no solo influye en el peso que tenemos, sino también en la aparición de enfermedades. Por eso, uno de los campos más prometedores de la IA en nutrición es su potencial para ayudar en la prevención y detectar riesgos de forma temprana.

Un ejemplo lo encontramos en el estudio de la microbiota intestinal, esas bacterias que viven en nuestro intestino y que tienen un papel tan importante en nuestra salud. Los algoritmos de aprendizaje profundo pueden analizar millones de secuencias de ADN de esas bacterias y descubrir cómo la dieta influye en su equilibrio. Con esta información se pueden identificar patrones asociados a obesidad o enfermedades como la inflamatoria intestinal antes de que los síntomas aparezcan.

En hospitales y residencias, la IA también comienza a ser una gran aliada. Gracias al análisis automático de datos como la variación de peso del paciente, sus registros de ingesta, sus analíticas y su evolución clínica, los sistemas inteligentes pueden detectar a tiempo quién tiene riesgo de desnutrición. Esto no solo mejora la atención clínica, sino que a la vez reduce costes al evitar complicaciones futuras.

Incluso en pruebas de imagen como la tomografía computarizada, el deep learning permite detectar la pérdida de masa muscular. Esto es muy importante en pacientes hospitalizados, ya que una detección temprana de nuevo previene complicaciones y mejora la recuperación.

Dietoterapia y nutrición clínica con ayuda de la IA

Cuando hablamos de nutrición en un entorno clínico, cada detalle importa. La cantidad de carbohidratos, proteínas o micronutrientes podría marcar la diferencia en la evolución de un paciente. Y es aquí donde la IA empieza a jugar un papel importante: no sustituye al profesional sanitario, pero sí puede ser un aliado para diseñar intervenciones más precisas y personalizadas.

La diabetes es un ejemplo: gracias a sistemas de visión computarizada, ahora es más fácil contabilizar los carbohidratos de un plato a partir de una simple foto. Esto ayuda a las personas con diabetes a autogestionar mejor sus comidas. Además, algunos desarrollos integran biomarcadores en tiempo real, como los niveles de glucosa, para ofrecer recomendaciones alimentarias adaptadas a la situación fisiológica de cada momento.

En el caso de pacientes oncológicos, también se han diseñado chatbots específicos para ellos que les acompañan en las diferentes fases del tratamiento ofreciendo consejos prácticos sobre alimentación para mejorar su bienestar.

En hospitales, la IA va más allá: modelos de machine learning permiten incluso ajustar en tiempo real las fórmulas de soporte nutricional enteral o parenteral, adaptándolas a los cambios clínicos del paciente. Esto optimiza la precisión de los tratamientos y reduce riesgos.

En definitiva, la IA no reemplaza la experiencia del profesional sanitario, pero sí se convierte en un apoyo fundamental en la toma de decisiones, contribuyendo a un cuidado nutricional más preciso, seguro y adaptado a la situación de cada paciente.

Investigación en nutrición: el papel de la IA

La IA también está revolucionando la investigación en nutrición. Con ella, hoy es posible realizar estudios más sólidos, personalizados y con un impacto directo en la práctica clínica del futuro.

En los estudios epidemiológicos, por ejemplo, la IA puede analizar datos de decenas de miles de personas para encontrar asociaciones entre dieta y salud que pasarían desapercibidas con las herramientas estadísticas tradicionales.

Otra de sus aplicaciones está en el aprendizaje no supervisado, que ayuda a segmentar a la población según sus patrones de alimentación. Esto quiere decir que se pueden crear perfiles de consumidores (o pacientes) y diseñar estrategias dietéticas específicas para cada grupo, aumentando así la eficacia de las intervenciones nutricionales.

Un campo especialmente prometedor dentro de la investigación actual es la nutrición de precisión. Aquí, la IA integra datos de biomarcadores, información sobre consumo de alimentos y medidas antropométricas como peso, talla o composición corporal. Aunque todavía es un enfoque en desarrollo, ya está sentando las bases para futuros tratamientos mucho más ajustados a perfiles genéticos o metabólicos específicos.

Un campo en evolución

Al final del día, gracias a estas herramientas Juan recibe una dieta ajustada a sus necesidades, y el equipo médico puede monitorear su evolución con datos precisos en tiempo real. Lo que comenzó como una simple foto de su bandeja de comida se integra en un sistema mucho más amplio, donde la IA ayuda a personalizar la nutrición y mejorar la salud de los pacientes.

Lejos de ser una herramienta del futuro, la IA ya es una realidad que está transformando la nutrición tanto en la práctica clínica como en la investigación. Su alcance va desde la automatización de tareas rutinarias como el registro de ingestas hasta análisis complejos que permiten personalizar intervenciones y avanzar en el descubrimiento científico.

El desafío en los próximos años será integrar la capacidad de análisis de la IA con la experiencia y juicio de los profesionales de la salud, sin olvidar la dimensión cultural, social y humana que caracteriza a la alimentación. ¿Estamos preparados?

Descubre Cómo Conseguir el GitHub Student Developer Pack y Usar Codex en VS Code

Adrian Algar — Thu, 25 Sep 2025 11:24:55 +0000

Si estás dando tus primeros pasos en el mundo del desarrollo o ya llevas un tiempo picando código, hay una herramienta que puede marcar la diferencia en tu aprendizaje: el GitHub Student Developer Pack. No es solo un conjunto de recursos, es una puerta de entrada a herramientas premium que normalmente serían de pago, pero que GitHub regala a estudiantes.

¿Lo mejor? Incluye GitHub Copilot, Visual Studio Code, Microsoft Azure, y mucho más.
Y si a eso le sumamos la extensión Codex para VS Code, que te permite integrar ChatGPT directamente en tu editor, el resultado es una experiencia de desarrollo potenciada por inteligencia artificial.

Por Qué Solicitar este Pack si Eres Estudiante

GitHub creó este pack con una misión clara: democratizar el acceso a herramientas profesionales PARA ESTUDIANTES. Aprender a programar no solo requiere tiempo y esfuerzo, también recursos que muchas veces son de pago. Este pack es la mejor opción para eliminar esa barrera.

Cómo Conseguir el GitHub Student Developer Pack

Obtenerlo es mucho más sencillo de lo que crees, siguiendo los pasos a continuación no tendrás problema para hacerte con el Pack:

1. Accede al sitio oficial: Entra al siguiente enlace: https://education.github.com/pack .

Una vez dentro, haz clic en “Sign Up for Student Developer Pack”.

2. Inicia sesión: Si ya tienes cuenta en GitHub, simplemente inicia sesión. Si no, créala.

CONSEJO: Usa tu correo institucional (.edu, .cat, etc.) para facilitar la verificación.

3. Comienza la solicitud: Haz clic en “Start application” y selecciona tu rol como estudiante. Luego, busca tu centro educativo en la lista o añádelo manualmente.

4. Verifica tu correo institucional: Si tu cuenta principal no es la de tu institución, puedes añadirla como secundaria en el apartado “Emails” y verificarla.

5. Adjunta documentación: Sube una credencial, constancia de matrícula o cualquier documento que pruebe que eres estudiante. GitHub te indicará qué tipo de prueba es más efectiva.

6. Permite la ubicación: GitHub te pedirá tu ubicación para verificar que estás en la institución. Si no estás allí, puedes explicar por qué (clases online, VPN, etc.).

7. Espera la verificación: Una vez enviada la solicitud, recibirás un correo cuando tu cuenta haya sido aprobada. ¡Y listo! Ya tienes acceso a todo el pack.

Beneficios que Incluye el Pack

Aprender más rápido: con herramientas como GitHub Copilot o Codex, puedes entender código, generar funciones, y resolver errores con ayuda de IA.

Construir proyectos reales: ya sea una web, una app o un bot, tienes acceso a hosting, bases de datos y entornos colaborativos.

Prepararte para el mundo laboral: muchas de estas herramientas son estándar en la industria. Usarlas desde ya te da ventaja cuando busques prácticas o tu primer trabajo.

Ahorrar dinero: si tuvieras que pagar por todo lo que incluye el pack, estarías desembolsando cientos de euros al año.

¿Y Codex en VS Code?

Codex es el complemento perfecto. Mientras el Student Pack te da acceso a herramientas, Codex te da asistencia inteligente dentro del editor. ¿Para qué sirve?

Resolver dudas sin salir del editor: puedes preguntarle a Codex qué hace una función, cómo se usa una API, o cómo solucionar un error.
Generar código automáticamente: describe lo que quieres hacer y Codex te propone una solución.
Aprender mientras haces: es como tener un mentor que te explica cosas mientras programas.

Codex no solo permite hacer las anteriores funciones, sino que también se integra con extensiones de Visual Studio Code que potencian esta experiencia.

Un ejemplo de cómo estas herramientas pueden transformar el aprendizaje autodidacta es: «Cómo Cursor Transformó mi Experiencia al Crear una Aplicación Web desde Cero», donde se explora el impacto de Cursor —una extensión basada en inteligencia artificial— en el desarrollo de proyectos reales.

Para empezar a usar estos útiles complementos en VS Code encontrarás los pasos a continuación.

Cómo Instalar Codex en Visual Studio Code

1. Busca la extensión en VS Code: Abre VS Code, ve a la sección de extensiones y busca “Codex – OpenAI”. Haz clic en “Install”.

2. Inicia sesión en ChatGPT: Una vez instalada, verás el icono de ChatGPT en la barra lateral. Haz clic y sigue las instrucciones para iniciar sesión.

3. Vincula tu cuenta: Introduce tus credenciales de ChatGPT y acepta los permisos. Codex no accede a tu historial de chats, solo vincula tu cuenta para poder usarlo desde VS Code.

Tu Iniciación al Mundo del Desarrollo Profesional

GitHub Student Pack y Codex no son solo recursos técnicos, son aceleradores de aprendizaje, puentes hacia el mundo profesional, y herramientas para crear SIN LÍMITE. ¡Si eres estudiante y te interesa la tecnología, este combo es una oportunidad que no deberías dejar pasar!

Haz un Juego de Pokemon con Python, Google Colab y IA, paso a paso

Santi — Fri, 28 Feb 2025 19:19:49 +0000

He creado un minijuego interactivo llamado Pokémon Quiz. La idea surge para combinar mi afición por los clásicos Pokémon con un poco de programación en Python, y lo he hecho todo en Google Colab. No es nada del otro mundo, pero es una excelente oportunidad para experimentar y aprender. Además, contar con la ayuda de ChatGPT facilita la organización de ideas y la estructuración del código, permitiéndome concentrarme en lo divertido.

Herramientas Utilizadas

Para armar Pokémon Quiz, me apoyé en varias herramientas y bibliotecas que me ayudaron a que todo funcionara:

Python: El lenguaje de programación que utilicé para escribir el código del juego.
Google Colab: El entorno en línea donde probé y compartí mi cuaderno interactivo.
ipywidgets: Estos widgets hicieron posible crear una interfaz gráfica sencilla y divertida.
Matplotlib: Me permitió mostrar imágenes y gráficos, como la silueta de los Pokémon.
Pillow (PIL): Con esta biblioteca, pude procesar las imágenes, descargarlas y generar las famosas siluetas.
PokeAPI: La fuente de los sprites oficiales de Pokémon, para que el juego tuviera ese toque auténtico.

Diseño y Estilo visual

Quería que el juego no solo funcionara bien, sino que también se sintiera auténtico y evocador de esos viejos tiempos. Por eso, me decidí por:

Tipografía Retro: Usé la fuente «Press Start 2P« de Google Fonts, perfecta para darle ese aire clásico.
Fondos y Colores: Elegí un fondo degradado en tonos amarillos y azules, muy en la onda de Pokémon, y añadí contenedores semitransparentes para que los elementos destacaran.
Interfaz Amigable: Desde la pantalla de inicio con el botón “PLAY” hasta la selección de la generación de Pokémon, cada parte fue diseñada para que el usuario se sienta cómodo y, sobre todo, se divierta.

¿Cómo Lo Hice?

El proceso de desarrollo se fue armando paso a paso, y aquí te lo cuento de forma sencilla:

Organización del Proyecto: Empecé creando un cuaderno en Google Colab, donde separé el código en secciones: una para importar las bibliotecas, otra para definir los estilos CSS, y otras para las funciones y la lógica principal del juego. Esto me ayudó a mantener todo ordenado.
Preparación de Funciones y Datos: Desarrollé funciones para descargar imágenes, convertirlas al formato adecuado para los widgets y generar las siluetas de los Pokémon. También definí diccionarios con las URLs de sprites de las diferentes generaciones (Gen 1 a Gen 5), lo que hizo que agregar nuevos Pokémon fuera muy sencillo.
Creación de la Interfaz: Utilicé ipywidgets para montar cada pantalla del juego:
- Una pantalla splash con el título y un botón “PLAY”.
- Una pantalla de selección de generación para elegir el grupo de Pokémon.
- La pantalla del juego, donde se muestra la silueta y se ofrecen opciones de respuesta.
- Y una pantalla de resumen que muestra tu puntaje y detalles de cada ronda.
Ajustes y Pruebas: No todo salió perfecto a la primera. Hubo momentos en que los botones no se comportaban como esperaba o las opciones no se actualizaban bien. Con varias pruebas en Colab y algunos consejos de ChatGPT, fui afinando cada detalle para que la experiencia fuera lo más fluida posible.

Ejemplo de Prompt a ChatGPT:
"El juego ya funciona, pero necesito un último ajuste: que toda la experiencia mantenga un estilo visual unificado con una estética inspirada en Pokémon. Quiero que se sienta como un videojuego, por lo que al iniciar, aparezca una pantalla con un botón 'PLAY' y, al hacer clic en él, comience el juego. ¿Puedes implementar estos cambios para lograr esa coherencia desde el inicio hasta el final?"
Como resultado, ChatGPT me devolvió este código donde se crean para que el juego se vea como se muestran en las capturas anteriores asegurando un estilo coherente y atractivo:


display(HTML('''


'''))

Conclusión

Pokémon Quiz es el resultado de poner en práctica ideas y herramientas que, aunque sencillas, se combinaron para crear algo entretenido y nostálgico. No se trata solo de código, sino de disfrutar el proceso, aprender de los errores y experimentar con la creatividad.

Si te animas a darle un vistazo o incluso a probar y modificar el código, ¡adelante! Cada cambio es una oportunidad para aprender y divertirse.

¡Pruébalo tú mismo!

¿Te gustaría experimentar con el código?

Haz clic aquí para abrir el cuaderno en Google Colab y probar el juego Pokémon Quiz.

⚔️ Deepseek R1 vs ChatGPT O1 para Estudiantes

Santi — Fri, 14 Feb 2025 09:43:34 +0000

En el mundo de la inteligencia artificial aplicada a la educación, dos nombres destacan por su capacidad para ayudar a los estudiantes: DeepSeek-R1 y ChatGPT-o1. En esta comparativa, exploramos sus fortalezas y debilidades para que puedas elegir la herramienta que mejor se adapte a tus necesidades académicas, ya sea para resolver problemas matemáticos, redactar ensayos o aprender algo nuevo.

DeepSeek-R1 se presenta como una opción práctica para estudiantes, ofreciendo precisión y velocidad en respuestas técnicas, ideales para materias como matemáticas, física y programación. Además, es 100% gratuito, lo que lo convierte en una opción accesible.

Por otro lado, ChatGPT-o1, desarrollado por OpenAI, es reconocido por su versatilidad y creatividad, integrando servicios adicionales como DALL-E para generar imágenes. Aunque sus respuestas pueden ser más detalladas, su versión de pago puede ser un obstáculo para algunos estudiantes.

1. Precisión y Velocidad

DeepSeek-R1

Precisión: Diseñado para ofrecer respuestas técnicas precisas, ideal para materias como matemáticas, física y programación.
Velocidad: Respuestas casi instantáneas, aunque en ocasiones el servidor puede mostrar el mensaje: «The server is busy. Please try again later.»
Ejemplo: Para resolver una integral compleja, DeepSeek-R1 te ofrece la respuesta correcta en segundos y sin rodeos.

ChatGPT-o1

Precisión: Ofrece respuestas detalladas, superando en algunos casos a DeepSeek-R1 en programación y explicaciones técnicas.
Velocidad: Rápido, aunque su desempeño puede variar según la carga del servidor.
Ejemplo: Para la misma integral, ChatGPT-01 brinda una explicación detallada, con pasos adicionales y ejemplos.

2. Facilidad y Ejemplo de Uso

DeepSeek-R1

Interfaz: Simple y directa, perfecta para respuestas rápidas.

Ejemplo

Prompt: «Vale, necesito crear un formulario para añadir vehículos que recoja la matrícula, la marca y el modelo de cada vehículo.»

Resultado

ChatGPT-o1

Interfaz: Intuitiva y fácil de usar, aunque con más opciones disponibles.

Ejemplo

Prompt: «Ahora quiero que cuando le de a desaparcar se me abra un pequeño formulario simulando el metodo de pago basandote en la tarifa del parking «

Resultado

3. Costo y Accesibilidad

DeepSeek-R1

Costo: Completamente gratuito, ideal para estudiantes.
Accesibilidad: Sin necesidad de suscripción o configuraciones adicionales.

ChatGPT-o1

Costo: Requiere una suscripción (ChatGPT Plus) para acceder a todas las funciones.
Accesibilidad: La versión gratuita es limitada en comparación con la de pago.

4. Servicios Adicionales

DeepSeek-R1

Enfoque: Centrado exclusivamente en el chat, lo que lo hace sencillo y directo.
Ventaja: Perfecto para estudiantes que solo necesitan respuestas textuales sin funciones adicionales.

ChatGPT-o1

Enfoque: Multifuncional, integrando servicios como DALL-E, Sora, opciones de audio y múltiples plugins.
Ventaja: Ideal para quienes buscan generar contenido visual, trabajar con audio o integrar herramientas adicionales.

5. Comparación de Uso

A continuación, se muestra el prompt exacto utilizado en ambas IAs y un breve video demostrativo:

Prompt Utilizado:

“Necesito que diseñes un diagrama UML de clases completo, utilizando notación UML estándar, basado en el contenido del siguiente enunciado del proyecto. El proyecto consiste en desarrollar una aplicación web para gestionar la bolsa de trabajo del instituto (CFGS DAW 2024-2025).

Requisitos y detalles a tener en cuenta:

Gestión de la bolsa de trabajo con actores: empresas y estudiantes.
Funcionalidades para el registro y gestión de empresas, ofertas de empleo, candidaturas, incidencias, noticias y ofertas externas.
Operaciones administrativas y de mantenimiento, incluyendo control de incidencias y notificaciones vía email.
Base de datos no relacional (MongoDB) con esquemas/documentos representativos.
El diagrama debe incluir clases, atributos, métodos y relaciones (herencia, asociación, composición).

Propósito: Base para la implementación del proyecto.”

Video Demostrativo

Conclusión Final: ¿Quién Gana?

DeepSeek-R1

Es la mejor opción para estudiantes por dos razones clave:

Es 100% gratis, algo crítico para un público joven que no siempre puede pagar suscripciones.
Ofrece la misma calidad en respuestas académicas que ChatGPT-01 (matemáticas, física, programación, etc.).

ChatGPT-o1

Vale la pena si:

Necesitas funciones premium (DALL-E, plugins, audio).
Tienes presupuesto para pagar una suscripción mensual.

Lovable vs. Bolt: ¿Cuál es la mejor opción para desarrollar una web app con Supabase?

Alan — Wed, 22 Jan 2025 17:11:29 +0000

En un mundo donde la inteligencia artificial simplifica el desarrollo de aplicaciones, dos herramientas destacan: Lovable y Bolt. Ambas prometen ayudarte a construir aplicaciones web en minutos, con integración directa con Supabase. Pero, ¿cuál elegir? En este artículo, compartiré mi experiencia usando ambas para desarrollar una aplicación de manejo de medicamentos y destacaré las diferencias clave.

El Desafío: Crear una app de manejo de medicamentos

La meta era clara: desarrollar una aplicación web para registrar medicamentos, programar recordatorios y gestionar información médica, todo con una base de datos alojada en Supabase. Como alguien que no es desarrollador profesional pero tiene curiosidad por herramientas de inteligencia artificial, quise comparar Lovable y Bolt para ver cuál simplificaba más el proceso.

Primera Diferencia: Cómo generan las aplicaciones

Lovable: Genera la aplicación por partes. Esto significa que trabajas página por página, dándole instrucciones específicas para cada sección. Por ejemplo, al crear una página para añadir medicamentos, tuve que definir los campos y configuraciones manualmente. Este enfoque te da más control, pero también requiere que estés más involucrado en cada paso del diseño y desarrollo. Ideal si quieres una experiencia «hands-on».
Bolt: Bolt toma un camino distinto: genera toda la aplicación de corrido. En minutos, obtienes una web app completamente funcional, con las páginas principales ya conectadas entre sí. Aunque esto ahorra tiempo, implica que tienes menos flexibilidad para ajustar detalles específicos durante la generación inicial.

Captura de pantalla del desarrollo con Lovable

Captura de pantalla del desarrollo con Bolt

Conectando con Supabase

Aquí es donde las diferencias se hacen más evidentes:

Lovable: Permite conectar fácilmente con proyectos existentes en Supabase. Solo necesitas tus credenciales de Supabase (URL y clave API), y Lovable configura las conexiones. Esto fue ideal para mi caso, ya que había configurado previamente una base de datos para manejar información de medicamentos. Además, la interfaz te guía paso a paso, lo que hace que sea sencillo interactuar con tablas ya creadas.
Bolt: Al conectar con Supabase, genera un proyecto nuevo en la plataforma. Esto puede ser útil si estás empezando desde cero, pero no es ideal si ya tienes datos o configuraciones existentes. Aunque la integración es rápida, me resultó menos flexible al intentar reutilizar bases de datos previamente configuradas.

¿Cuál es más fácil de usar?

Lovable: Su enfoque por partes es más intuitivo si te gusta tener control sobre cada detalle. Sin embargo, puede ser un poco más laborioso si buscas rapidez.
Bolt: Es extremadamente fácil para quienes quieren un producto funcional de inmediato. Pero si necesitas personalizar detalles durante el proceso inicial, puede quedarse corto.

Personalización y Escalabilidad

Lovable te permite construir cada componente de forma personalizada, lo que facilita adaptar la app a necesidades específicas. Es ideal para proyectos donde cada página tiene funcionalidades únicas.
Bolt prioriza la velocidad, generando un esquema estándar que puede requerir ajustes posteriores si tu proyecto es más complejo.

Mi Elección

Para el desarrollo de mi app de manejo de medicamentos, comencé con Lovable. Su flexibilidad al trabajar con bases de datos existentes en Supabase fue crucial para mi proyecto. Sin embargo, exploré Bolt cuando necesitaba generar rápidamente una versión funcional para probar ideas.

Ambas herramientas son útiles dependiendo del caso de uso:

Si valoras el control y la personalización, Lovable es la mejor opción.
Si necesitas rapidez y estás iniciando desde cero, Bolt te ahorrará tiempo.

En conclusión, las herramientas como Lovable y Bolt están democratizando el desarrollo de aplicaciones, permitiendo que personas sin formación en programación creen soluciones funcionales. Sin embargo, la elección entre ambas depende de tus necesidades específicas y de cómo quieras interactuar con tu base de datos en Supabase.

Te invito a revisar dos versiones de la misma idea una usando Lovable y la otra usando Bolt.

MediManage en Lovable: https://health-vista-tracker.lovable.app

MediManage en Bolt: https://bespoke-ganache-900d45.netlify.app