ChatGPT y Scratch (MIT)

Sigo sorprendiéndome con las posibilidades de la inteligencia artificial generativa. 

En una clase con estudiantes de secundaria estábamos abordando la creación de videojuegos, sus mecánicas y la “inspiración”: cómo tomar una idea conocida para crear algo propio.

Para mostrar una posibilidad, le pedí a ChatGPT un juego sencillo, basado en la mecánica de Super Mario Bros. La protagonista debía ser una maestra, los libros servirían para sumar puntos y los pupitres serían obstáculos. Quería algo simple, pero visualmente atractivo.

La respuesta fue un videojuego en HTML, CSS y JavaScript: “Profe Saltarina”.

Después se me ocurrió preguntar: ¿Podés hacerlo en Scratch, del MIT?

Quería ver hasta dónde llegaba

ChatGPT me ofreció dos caminos: explicarme paso a paso cómo construirlo o preparar un proyecto descargable.

Elegí que lo preparara. Quería probar qué podía generar y qué encontraría al abrirlo.

Me entregó un archivo .sb3 que pude cargar en Scratch. Allí estaban el escenario, la maestra, los libros, los pupitres y los movimientos básicos.

Era un prototipo. Al probarlo, comprobé que todavía faltaban colisiones, puntaje y otras mecánicas para que funcionara como el juego que había imaginado.

Hasta hace poco esto era imposible. La IAG podía programar en lenguajes tradicionales, pero no en bloques y dejar el proyecto listo para usar.

Lo que me dieron ganas de probar

Mientras lo exploraba, empecé a imaginar propuestas para continuar con los estudiantes:

• ¿Cómo está programado el movimiento de la maestra?

• ¿Qué tendríamos que agregar para que tocar un libro sume puntos?

• ¿Cómo podemos convertir los pupitres en obstáculos?

• ¿Qué otras reglas podríamos inventar para darle una identidad propia al juego?

• ¿La lógica es correcta? 

• ¿Es la única forma de resolverlo?

Son posibilidades que quiero seguir explorando. Me interesa averiguar qué sucede cuando llevamos al aula un proyecto inicial generado con IA y proponemos comprenderlo, ponerlo a prueba y transformarlo.

El juego se abre, la maestra se mueve y puede saltar. Pero ¿hace todo lo que pedimos?

Ahí encuentro una oportunidad para desarrollar el pensamiento crítico: comparar lo que pedimos, lo que la herramienta dice haber hecho y lo que efectivamente ocurre al probarlo. Reconocer qué está resuelto, qué falta y cómo podríamos mejorarlo.

Ese “funciona, pero…” puede ser el comienzo de una investigación con los estudiantes.

Comparto Profe Saltarina en Scratch. Se puede probar, mirar por dentro y usar como punto de partida para hacer una versión propia.

¿Qué desafío les propondrían a sus estudiantes a partir de este prototipo?

Lovable: crear simulaciones con IA a partir de un prompt

 

Investigando material para la escuela secundaria como parte de un trabajo de creación de módulos educativos para todos los niveles sobre el uso de IA en el aula, me encontré con Lovable, una herramienta no-code impulsada por inteligencia artificial que permite crear aplicaciones web y productos digitales a partir de descripciones en lenguaje natural.

Yo estaba escribiendo sobre la posibilidad de hacer simulaciones con IA. La idea era pensar cómo un docente de secundaria podría construir una experiencia interactiva sin necesidad de programar desde cero, pero con suficiente sentido pedagógico como para trabajar datos, variables, escenarios y análisis crítico.

El tema elegido fue: humedales de Entre Ríos, impacto en la fauna autóctona a partir de la urbanización.

Imagen hecha con chatGPT

Mi prompt fue:

"Quiero diseñar una simulación simple para estudiantes de secundaria sobre humedales de Entre Ríos y urbanización.

El objetivo es analizar qué podría ocurrir con la fauna autóctona si cambia la superficie de humedal conservada, aumenta la urbanización o se implementan medidas de protección ambiental.

Ayudame a identificar:

1. variables principales;

2. posibles escenarios;

3. consecuencias esperadas en cada escenario;

4. datos que podríamos buscar o recolectar;

5. preguntas para que los estudiantes analicen los resultados;

6. límites de la simulación, es decir, qué aspectos de la realidad quedarían simplificados."

Para este prompt, tuve primero que pensar el modelo didáctico: qué variables iban a intervenir, qué escenarios podían compararse, qué datos sería necesario buscar y qué límites tendría la simulación. (Para ello también me ayudo la IA + materiales educativos/publicaciones)

A partir de ese pedido, Lovable generó una aplicación funcional. La simulación permite modificar variables como:

• superficie de humedal conservada;

• avance de la urbanización;

• medidas de protección ambiental.

Humedales de Entre Ríos · Simulación interactiva

A medida que se mueven esos controles, la aplicación muestra cómo podrían variar indicadores vinculados con la biodiversidad y con la población relativa de distintas especies de fauna autóctona.

Esto me pareció muy potente. No porque la simulación sea una predicción exacta de lo que ocurrirá en un ecosistema real, sino porque permite abrir preguntas: ¿qué pasa si se conserva más superficie de humedal?, ¿qué ocurre cuando avanza la urbanización?, ¿qué especies resultan más afectadas?, ¿qué medidas de protección podrían tener mayor impacto?, ¿qué datos reales necesitaríamos para mejorar el modelo?

La simulación, entonces, funciona como una herramienta para pensar. Permite comparar escenarios, formular hipótesis, discutir relaciones entre variables y analizar los límites de una representación simplificada de la realidad.

También me pareció interesante que Lovable no se queda solo en la primera versión. Una vez creada la aplicación, la propia herramienta sugiere caminos posibles para seguir desarrollándola: agregar fichas de especies, incluir fuentes de datos, permitir exportar resultados o sumar un mapa del paisaje.

Esto abre una posibilidad muy valiosa para el aula: trabajar con prototipos. La primera versión no tiene por qué ser la definitiva. Puede revisarse, mejorarse, ajustarse y discutirse. Incluso los estudiantes podrían analizar qué variables faltan, qué información debería incorporarse, qué datos habría que verificar o qué aspectos del modelo resultan demasiado simplificados.

Desde una mirada pedagógica, Lovable permite acercarse a algo que muchas veces parece lejano para docentes que no programan: la creación de aplicaciones interactivas. El punto de partida no es escribir código, sino describir con claridad qué se quiere construir.

Por supuesto, esto no elimina la necesidad de revisar críticamente lo que la herramienta produce. Una simulación generada con IA puede incluir supuestos discutibles, relaciones poco justificadas o resultados que no estén basados en datos reales. Por eso, antes de llevarla al aula, conviene preguntarse:

• ¿qué variables incluye?

• ¿qué variables deja afuera?

• ¿de dónde salen los valores?

• ¿qué relaciones establece entre los datos?

• ¿qué tan realista es el modelo?

• ¿qué habría que ajustar para que dialogue mejor con el contenido trabajado?

Ojo, HOY es gratuita, pero con créditos diarios. En mi caso, me dio 10 créditos iniciales, que alcanzaron muy bien para generar la simulación. Por eso, conviene pensar bien el prompt inicial antes de comenzar: cuanto más claro sea el pedido, más posibilidades hay de obtener una primera versión útil sin consumir demasiados intentos.

La verdad, me asombró y le veo muchas posibilidades: simulaciones sobre ambiente, consumo de energía, movilidad urbana, uso de pantallas, propagación de rumores, presupuestos, convivencia escolar o decisiones comunitarias. En todos los casos, la clave no está solo en la herramienta, sino en la calidad de la pregunta didáctica. Nuevamente, el vibe coding está presente.

Lovable no reemplaza la planificación docente ni el análisis crítico. Pero puede convertirse en una puerta de entrada muy interesante para diseñar experiencias interactivas, trabajar con variables, comparar escenarios y acercar a los estudiantes a formas de pensamiento computacional sin que la programación sea una barrera inicial.

La herramienta se puede explorar en: lovable.dev

Antes de Google: tecnología, vínculos y memoria cuando nada era instantáneo

 

Ordenando cosas viejas aparecieron unos ZIP y un lector Iomega.

No es nostalgia. Es infraestructura.

Esos discos guardan parte de un proyecto en el que trabajé a fines de los ’90 / comienzos de los 2000: el Registro Único de Bienes Culturales (RUBC) de la Ciudad de Buenos Aires.

Discos Zip y lector Iomega utilizados en proyectos tecnológicos a fines de los años 90

En ese momento, buscar información no era algo obvio. Google todavía no formaba parte de la vida cotidiana y la web, tal como hoy la conocemos, estaba lejos de ser un espacio estable, rápido y permanente. El patrimonio cultural -obras, objetos, documentos, cuadros- vivía disperso en museos, archivos y bibliotecas, mayormente en soportes analógicos.

La idea del RUBC era ambiciosa: construir una gran base de datos digital del patrimonio cultural de la ciudad, integrando información que hasta entonces estaba fragmentada y, muchas veces, inaccesible.

Trabajo distribuido, cuando internet casi no existía

Formé parte del equipo técnico del proyecto, como especialista y programadora en Lotus Notes, trabajando con su lenguaje, LotusScript. En la última etapa, también coordiné a otros programadores.

Lotus Notes

El equipo no era solo técnico.
Para mí, además, era profundamente personal.

Mi padre formaba parte del equipo de coordinación del proyecto. Fue una figura clave en ese entramado entre cultura, gestión y tecnología, y también —mucho más allá de este trabajo— el pilar que me llevó a elegir y sostener esta profesión. Hoy ya no está, pero su huella atraviesa todo lo que hago.

Yo trabajaba codo a codo con mi mejor amiga, Karina Valdetari, que hoy es la madrina de mi hija. Con ella hicimos este y muchísimos otros proyectos a lo largo de los años. En ese momento yo era programadora, ella la analista; hoy seguimos compartiendo camino profesional, ambas vinculadas a Ceibal y Chicos.net, trabajando en educación y en el cruce con la informática y las ciencias de la computación.

Mirado en perspectiva, el RUBC no fue solo un proyecto tecnológico: fue también un espacio de vínculos, aprendizajes compartidos y una manera de entender la tecnología como herramienta cultural y educativa.

Cargar, replicar, buscar

Uno de los mayores desafíos era la conectividad. Internet estaba en pañales: módems lentos, conexiones inestables, tiempos de espera que hoy serían impensables.

Ahí es donde Lotus Notes fue clave. Cada museo podía cargar contenido de manera local, desconectado de la red: fichas, descripciones, datos curatoriales. Luego, cuando había conexión, se hacía una replicación con el servidor central.

Lo interesante es que no se replicaba todo: el sistema enviaba solo las altas y actualizaciones, lo que reducía enormemente los tiempos de transferencia. Las imágenes, mucho más pesadas, se cargaban en el servidor central una vez que el contenido textual ya había sido curado y replicado. Primero la información, después lo visual.

En el servidor central, los datos se consolidaban, se exportaban en XML y se levantaban en una base PostgreSQL. Todo ese recorrido hoy parece normal; en ese momento era bastante experimental.

El momento “esto es increíble”

El resultado era poderoso.

Poder entrar a una página desde cualquier parte del mundo, escribir “sable corvo de San Martín” y que el sistema devolviera imágenes, descripciones y referencias a museos donde encontrar información relacionada era, literalmente, increíble.

No porque el sable no existiera, sino porque la idea misma de buscar patrimonio cultural de esa manera no existía todavía.

Impacto real

El sistema se usó. Y mucho.

Llamaban desde otros países para pedir información o materiales. Recuerdo especialmente pedidos de Japón de partituras de Gardel, entre otros. El patrimonio empezaba a circular de otra manera: menos encerrado, más accesible, más vivo.

Hubo también un acto institucional de presentación en el Teatro San Martín, encabezado por Aníbal Ibarra, que en ese momento era jefe de Gobierno de la Ciudad. Era una señal clara de que no se trataba de un experimento aislado, sino de una política cultural con visión de futuro.

Menos de 30 años después

Hoy, acomodando cosas, aparecen estos ZIP como una cápsula del tiempo.
No guardan solo datos ni código: guardan personas.

Guardan a mi padre, que fue quien me enseñó que la tecnología tenía sentido si estaba al servicio de algo más grande.
Guardan una amistad que atravesó proyectos, años y etapas de la vida, y que todavía hoy sigue ligada a la educación.

El RUBC sigue existiendo.
Yo sigo trabajando en educación y tecnología.
Muchas de las personas de entonces seguimos creando, enseñando y construyendo, hoy con otras herramientas, pero con la misma convicción.

Hoy buscamos sin pensar.
En ese momento, buscar era una apuesta.

Y estos discos, lejos de ser recuerdos, son una prueba silenciosa de que el presente digital se construye con capas de historia, de código y, sobre todo, de personas.

Andrea - enero de 2026

Una verdad incómoda: el Vibe coding, la IA como copiloto, sirven

Programo desde hace muchos años. Pasé por Pascal, Visual Basic, la programación orientada a objetos con Java, la llegada de Python y todo lo que vino después. Durante décadas, crear un producto “bien hecho” parecía estar reservado a quienes dominaban lenguajes, frameworks, librerías, configuraciones y un vocabulario técnico cada vez más extenso.

Si no te actualizabas permanentemente, la puerta parecía cerrada.

Lo que sucedió ayer terminó de confirmar algo que vengo intuyendo desde hace tiempo: ese paradigma está cambiando.
No porque el conocimiento técnico haya dejado de importar, sino porque ya no es el único camino.

Tenía que entregar un prototipo de un formulario. Funcionaba, era correcto, pero era frío. Minimalista, sin alma. La experiencia de usuario no invitaba, no acompañaba, no decía “acá hay alguien del otro lado”.

Necesitaba cambiarlo. Y rápido.

Y ahí recurrí a ChatGPT. 

No voy a decir que fue “sin código”. Hubo código.
Pero no fue coding en el sentido tradicional de sentarse a escribir línea por línea sabiendo exactamente qué hace cada cosa.

Fue otra cosa.

Fue vibe coding.

¿Qué quiero decir con vibe coding?

• saber qué quiero lograr

• tener claro para quién

• reconocer cuándo algo “no funciona” aunque compile

• y, sobre todo, hacer las preguntas correctas

La diferencia no estuvo en dominar React, Tailwind, Vite o Vercel (no los domino en profundidad), sino en el criterio: pedagógico, comunicacional y de experiencia de usuario.

En este proceso, la inteligencia artificial no fue “la que hizo todo”.
Fue coach, par de programación, espejo y traductor.

No escribí:

“Haceme un formulario”.

Escribí cosas como:

• "¿Cómo modifico el código para poder embeberlo en Google Sites?"

• “¿Me explicás cómo creo el proyecto Vite?”

La IA no reemplazó mis decisiones.
Me ayudó a iterar más rápido, a probar caminos, a salir de atolladeros técnicos y, sobre todo, a no abandonar cuando lo técnico se volvía ruido.

Sin saber “cómo se hace” en términos técnicos profundos, pero sí sabiendo que necesitaba transmitir, fuimos logrando el prototipo de la página deseada con el formulario embebido.

Esto no demuestra que “ya no hace falta saber nada”. Si no tuviese todos los años y experiencia que tengo encima, es probable que hubiese abandonado en los primeros comandos que hubo que tirar al Powershell. Demuestra que hoy es posible construir cosas valiosas sabiendo lo suficiente y preguntando bien. 

Mis conocimientos previos fueron el suelo.
La IA fue el andamio.
El resultado: un prototipo funcional.

Esto abre una puerta enorme:

• prototipar sin depender de equipos técnicos grandes

• probar ideas antes de institucionalizarlas

• diseñar experiencias con foco en las personas

• y recuperar la sensación de “sí, esto lo puedo hacer”

Tal vez el verdadero cambio no sea técnico, sino cultural.

Tenemos que aprender a preguntar, partiendo de una base sólida de conocimientos sobre el tema.