Por qué programamos así — y por qué enseñarlo de otra forma ya no tiene sentido
Ya habréis notado que este curso no va de memorizar sintaxis. Esta sesión lo pone negro sobre blanco: qué está pasando ahí fuera, qué se espera de vosotros como desarrolladores, y por qué estamos pilotando una forma de enseñar que casi nadie está atreviéndose a llevar al aula.
Los datos: la IA ya está en el código y en el aula
No es una opinión ni una moda: es cómo trabaja hoy la industria y cómo estudia ya vuestra generación. Tres cifras verificables:
Lo que ha cambiado: tu rol ya no es teclear, es decidir
Durante décadas, programar se enseñaba como dominio de sintaxis: escribir desde cero, de memoria, líneas y líneas. Con agentes que escriben esas líneas en segundos, enseñar eso es enseñar una habilidad que el mercado ya no contrata. Lo que el mercado sí contrata, y lo que este curso entrena, es el nivel superior:
🎯 Especificar
Traducir lo que quieres a un encargo claro y acotado. Un prompt vago produce un desastre con buena caligrafía.
🔍 Verificar
Probar, dudar, detectar lo que suena bien pero está mal. La IA se equivoca con total seguridad: tu criterio es el cortafuegos.
🧭 Dirigir
Arquitectura, git, alcance, prioridades. Lo que un senior hace con su equipo, hoy un desarrollador lo hace con sus agentes.
Y aquí entra la parte de innovación
Este enfoque no es improvisado: el IES Simarro lo está pilotando dentro de su Programa de Excelencia, como proyecto de innovación educativa —de los pocos de FP en España que se atreven a reescribir cómo se enseña a programar, no solo a añadir «IA» al título del tema. La apuesta, documentada sesión a sesión en esta web para que cualquiera pueda replicarla o criticarla con datos:
- • Proyectos, no temas: se aprende construyendo (web personal → GitHub → proyectos con agentes → finales individual y en grupo).
- • IA como herramienta estándar, no como trampa: la usarás en clase, en entregas y en evaluación, con la exigencia de dirigir.
- • Evidencia pública: GitHub como portafolio y esta web como memoria del método. Si funciona, se exporta; si falla, se corrige en público.
public static void main.La rúbrica con la que se corrige vuestra web de marca
Que la IA te monte una web en cinco minutos no es mérito: eso lo hace cualquiera. Lo que se evalúa es el trabajo que hay detrás: lo que especificaste, lo que añadiste, lo que arreglaste, lo que sabes explicar. Esta es la rúbrica completa — úsala como hoja de ruta: cada casilla que subas de nivel son puntos, y casi todas se consiguen con una buena orden a tu agente. Sobre 100 puntos, con requisitos mínimos obligatorios antes de nada.
- ✓ La web carga en producción (GitHub Pages) sin errores en consola (F12 limpio).
- ✓ Un visitante puede ponerse en contacto contigo y eso funciona de verdad: formulario que envía (formspree/Web3Forms), o chatbot con tu clave API del centro que responde, o al menos
mailto:/teléfono visibles y correctos. Un botón «Contacto» que no hace nada = suspenso directo. - ✓ Se ve bien en el móvil (probado con DevTools → modo dispositivo, no solo en tu portátil).
- ✓ Historial git real: mínimo 10 commits con mensajes que cuentan el proceso (no un único «web final»).
| Criterio (peso) | Insuficiente · 0% | En desarrollo · 50% | Competente · 80% | Excelente · 100% |
|---|---|---|---|---|
| Contacto real y funcional15 pts Que un desconocido pueda escribirte desde la web y te llegue. | Enlace roto, botón muerto o mail inventado. | mailto: o teléfono visible y correcto, sin más. | Formulario que envía de verdad (Formspree/Web3Forms/GitHub Issue) con validación y mensaje de éxito. | Canal con respuesta automática: chatbot con la API del centro, auto-responder por correo, o formulario que abre un issue/PR etiquetado — y sabes explicar el recorrido del dato. |
| Contenido propio y densidad15 pts Una web de marca se define por qué dice de TI, no por su plantilla. | Solo el texto genérico que soltó la IA en el primer prompt. | 1-2 secciones con algo tuyo (fotos, algún trabajo). | 4+ secciones coherentes: sobre mí, proyectos con contexto, servicios/habilidades, experiencia; textos revisados por ti, sin humo. | Además: casos de proyecto reales con problema→solución→resultado, datos o métricas propias, y una voz reconocible (se nota quién eres sin leer el nombre). |
| Diseño y coherencia visual15 pts Que parezca una marca, no una demo de plantilla. | Colores y tipografías aleatorias; roto en móvil. | Plantilla correcta pero impersonal; responsive básico. | Sistema coherente: paleta y tipografía deliberadas, espaciados regulares, responsive real en 3 anchos, modo oscuro que suma. | Identidad propia defendible: logo/favicon hechos por ti, microinteracciones, consistencia en 4+ páginas, y sabes justificar cada decisión de diseño. |
| Riqueza de medios10 pts Imágenes, SVG, vídeo, animación: el contenido multimedia cuenta la historia. | Solo texto o una foto de stock. | Imágenes variadas sin optimizar (peso, alt, lazy). | Mezcla trabajada: fotos propias optimizadas, ≥2 SVG propios (iconos/illustraciones), vídeo embebido, animaciones CSS/JS que aportan. | Todo lo anterior con criterio: SVG animados propios, vídeo propio o demo grabada, animaciones con intención (no decorativas), Lighthouse media sin avisos. |
| Interactividad y funcionalidad extra15 pts Lo que une el 'te hace una web' con el 'has construido una aplicación'. | Solo enlaces ancla y algún acordeón de serie. | Alguna interacción cosmética (hover, carrusel). | ≥2 funciones reales: menú móvil propio, buscador/filtro de proyectos, formulario validado, calculadora, test, dark-mode con persistencia. | Función con estado o datos: login demo con zona interna, consumo de una API externa real, chatbot operativo, o personalización según parámetros — con el código explicado en la defensa. |
| Arquitectura, calidad técnica y accesibilidad15 pts Cómo está montado por dentro: semántica, estructura, rendimiento. | Un index.html gigante con estilos inline, sin carpetas. | Estructura de ficheros razonable pero HTML no semántico. | HTML semántico, CSS organizado (variables/tokens), JS modular, <title>/meta/OG por página, contraste y foco accesibles, alt en imágenes. | Además: componentes reutilizables o templates, Lighthouse ≥90 en rendimiento/accesibilidad, y ADR o README técnico explicando 2 decisiones de arquitectura. |
| Proceso: git, iteración y evidencia de trabajo15 pts El corazón del curso: el trabajo detrás, visible en el historial. | 1-2 commits monolíticos. | 3-9 commits con mensajes flojos ('cambios', 'final'). | ≥10 commits atómicos con mensajes que cuentan decisiones + ramas para las features grandes. | Historial que se puede leer como un diario: issues/PR, iteraciones visibles, v1→v2 con mejoras rastreables, y las órdenes clave a la IA archivadas en el repo. |
Para cerrar el círculo: vuestra opinión
Parte de esta sesión es escucharos, porque el método se ajusta con evidencia — la vuestra primera. Reflexiona y comparte (la usaremos para mejorar el curso):
- 1 · ¿Qué has aprendido haciendo la web que no creías que ibas a aprender?
- 2 · ¿En qué momento la IA te dio algo «que parecía bien pero no lo estaba» y cómo lo detectaste?
- 3 · ¿Qué parte del curso te resulta menos clara o menos justa? Propón el cambio.
Con esto queda justificada la forma de trabajar. Lo que viene ahora es lo serio: los dos proyectos finales, donde todo esto se pone a prueba de verdad.