Hace ocho meses empecé a desarrollar el software con el que a mí me habría gustado aprender a programar PLC. Quería algo práctico, con ejercicios reales, programación en Structured Text y Ladder, un entorno donde poder probar, equivocarme y entender qué estaba pasando. La idea la tenía bastante clara. El problema era que no tenía ni idea de cómo convertirla en un programa real.
Y ahí empezó la aventura.
Al principio pensé que bastaba con abrir ChatGPT, explicarle lo que quería y seguir trabajando en el mismo chat hasta terminar el proyecto. Sobre el papel parecía lógico. En la práctica, no tanto.
Durante las primeras semanas fui añadiendo funciones, corrigiendo cosas y ampliando el proyecto en una única conversación. Al principio todo funcionaba razonablemente bien, pero cuanto más crecía el chat, más difícil era mantener una línea de trabajo estable. Llegaba un momento en el que tenía que recordarle constantemente decisiones que ya habíamos tomado, explicarle otra vez cómo estaba organizado el proyecto o avisarle de que no se desviase de lo que habíamos acordado.
Además, la conversación se iba volviendo cada vez más lenta. Lo que al principio parecía una buena idea terminó convirtiéndose en una especie de monstruo digital al que había que explicarle continuamente quién era, qué estaba haciendo y por qué llevaba cientos de mensajes trabajando en un PLC virtual.
Empezamos de 0
Esta vez intenté hacerlo mejor. Le pedí a ChatGPT que me preparase un índice completo con todos los puntos que debía desarrollar. La idea era sencilla: si teníamos una estructura clara, podríamos avanzar paso a paso sin perdernos.
Funcionó mejor, pero seguía arrastrando el mismo problema: todo estaba dentro del mismo chat.
Durante bastante tiempo trabajé así y, sinceramente, hubo momentos frustrantes. Yo sabía perfectamente cómo quería que fuese el producto, pero no sabía cómo convertir esa idea en código. Podía imaginar la interfaz, los ejercicios, cómo debía comportarse un temporizador o qué experiencia quería que tuviese una persona al utilizar el programa, pero entre imaginarlo y tenerlo funcionando había un mundo.
Y había algo que tenía bastante claro: no quería esperar años a aprender programación antes de empezar.
Siempre he sido bastante de meterme en problemas por intentar solucionar cosas. Soy la típica persona que un día quiere arreglar su ordenador y acaba montando una empresa de informática y arreglando ordenadores a media ciudad. Así que, evidentemente, lo razonable habría sido estudiar programación con calma antes de intentar construir un simulador de PLC.
Hice justo lo contrario.
En algún momento tuve una de esas ideas que después parecen obvias: ¿y si dividía el proyecto por fases y utilizaba un chat diferente para cada una?
En lugar de intentar construir un software entero dentro de una conversación interminable, podía dividirlo en piezas pequeñas. Una fase para una parte del núcleo, otra para determinados bloques, otra para la interfaz, otra para los ejercicios y así sucesivamente.
Lo probé y funcionó sorprendentemente bien.
Eso sí, apareció inmediatamente otro problema. Yo daba por hecho que el siguiente chat sabría lo que había ocurrido en el anterior. Spoiler: no.
Abrías una nueva conversación y era como contratar a una persona nueva para un proyecto de ocho meses y decirle: “Bueno, seguimos por donde lo dejamos”.
¿Dónde lo dejamos exactamente?
La solución terminó siendo bastante sencilla. Al finalizar cada fase le pedía a ChatGPT que preparase una documentación completa para el siguiente chat. Tenía que explicar qué habíamos desarrollado, cómo estaba organizada la estructura de archivos, qué decisiones técnicas habíamos tomado, qué funciones existían, qué quedaba pendiente y cómo debía continuar el trabajo.
Después copiaba ese documento en una nueva conversación y seguíamos desde ahí.
En la práctica, cada chat se convertía en una pequeña etapa del proyecto y la documentación actuaba como relevo entre una fase y la siguiente. Aquello cambió mucho mi manera de trabajar y durante bastante tiempo fue el sistema que utilicé.
Pero todavía quedaba una pequeña cuestión: yo no sabía realmente si todo aquel código funcionaba.
Podía ver cientos de líneas perfectamente ordenadas, funciones con nombres muy serios y estructuras que parecían profesionales, pero para mí aquello podía ser un PLC virtual o la receta de una tortilla de patatas escrita en Python. Así que le pedí a ChatGPT que crease pruebas automáticas para comprobar que las diferentes partes del programa hacían lo que debían hacer.
Los tests se ejecutaban y pasaban.
Perfecto.
Hasta que pensé: “¿Y si los tests están hechos de manera que siempre salgan bien?”.
Y sí, se lo pregunté al mismo ChatGPT que había creado los tests.
No era exactamente una auditoría independiente.
Aun así, llega un momento en cualquier proyecto en el que tienes que confiar un poco y continuar. Y eso hice.
Con este método conseguimos construir lo que podríamos llamar el corazón del PLC. Ya existía una lógica interna, instrucciones, bloques y diferentes partes que, en teoría y mediante las pruebas, funcionaban correctamente.
Entonces llegó el momento en el que todo empezó a hacerse mucho más tangible: la interfaz gráfica.
Hasta ese punto gran parte del trabajo eran archivos y código. Con la interfaz, por primera vez podía abrir el programa, pulsar cosas y comprobar visualmente si lo que habíamos construido tenía sentido.
Empezamos con Structured Text porque era relativamente sencillo representar un editor de texto y conectarlo con el motor que ya habíamos desarrollado. Después llegó Ladder y el proyecto empezó a parecer realmente lo que yo había imaginado meses atrás.
También fue entonces cuando descubrí otra gran lección del desarrollo con IA: las copias de seguridad son tus amigas.
Trabajando con ChatGPT tenía que copiar partes del código, explicar qué había en determinados archivos y pedir modificaciones concretas. La mayoría de las veces funcionaba bien, pero de vez en cuando la IA podía interpretar algo de una manera diferente a la que yo esperaba y tocar más de lo necesario.
Cuando eso ocurre en un proyecto grande, la palabra “estropicio” empieza a quedarse corta, por eso empecé a hacer copias de seguridad antes de prácticamente cualquier cambio importante, naturalmente, esta brillante costumbre apareció después de aprender la lección por las malas.
Y entonces llegó Codex.
Al principio era bastante reacio a utilizarlo. Hasta ese momento, aunque yo no supiese programar realmente, tenía la sensación de que controlaba el proceso. Copiaba el código, veía lo que se modificaba y poco a poco iba entendiendo cómo estaba construido el proyecto.
Permitir que una IA accediese directamente a mis archivos y empezase a modificar el código me generaba cierta desconfianza. Sentía que iba a perder parte de ese control y también parte del aprendizaje que estaba obteniendo durante el proceso.
Pero un día decidí probarlo.
Codex hizo en diez minutos trabajos que con mi método anterior podían ocuparme varios días o incluso una semana. Ya no tenía que copiar el contenido de cada archivo, explicar manualmente cómo estaba organizada cada carpeta o pegar fragmentos enormes de código en una conversación. Podía analizar el proyecto completo, entender la estructura y trabajar directamente sobre ella.
La diferencia de velocidad fue enorme, pero curiosamente no fue lo que más me llamó la atención. Lo que realmente descubrí fue que, hasta ese momento, el proyecto estaba limitado por mis propios límites.
Yo pedía aquello que sabía que podía existir. Diseñaba las funciones según lo que conocía. Planteaba soluciones basadas en mi experiencia y en lo que era capaz de imaginar.
Codex empezó a proponer estructuras, reorganizaciones y soluciones que yo probablemente nunca habría planteado por mi cuenta. Y eso hizo que el proyecto empezase a crecer mucho más allá de la idea original.
Lo que inicialmente iba a ser una herramienta sencilla para aprender programación de PLC se fue convirtiendo en un entorno de automatización bastante más completo. Actualmente incluye programación en Structured Text y Ladder, ejercicios prácticos, SCADA, un editor SCADA libre para diseñar circuitos propios, bloques de funciones, memorias, tags, varios idiomas y otras funciones que ni siquiera estaban en el planteamiento inicial.
Y seguramente dentro de unos meses volveré a leer esta lista y estará desactualizada.
Después de ocho meses trabajando de esta manera, creo que lo más interesante que he aprendido no tiene que ver realmente con programación.
Tiene que ver con la relación entre una persona y una inteligencia artificial.
Porque Codex puede escribir código mucho mejor y mucho más rápido que yo. Puede revisar cientos de archivos, encontrar errores, reorganizar estructuras, crear pruebas y desarrollar funciones complejas. Pero sigue necesitando algo de mí.
- Necesita saber qué producto estamos construyendo.
- Necesita entender qué experiencia quiero que tenga la persona que lo utilice.
- Necesita que alguien decida qué funciones tienen sentido y cuáles no. Necesita prioridades, criterio, contexto y una dirección.
En definitiva, necesita una visión.
Durante mucho tiempo pensé que para crear un software de este nivel primero tendría que aprender programación, diseño, arquitectura de software y probablemente pasar varios años acumulando experiencia.
Ahora lo veo de una forma diferente.
No necesito saber personalmente cómo hacer cada una de las cosas que forman el producto. Necesito comprender qué quiero construir, cómo quiero que funcione y ser capaz de explicarlo con suficiente precisión para que la inteligencia artificial pueda ayudarme a convertirlo en realidad.
Eso no significa que el conocimiento técnico deje de ser importante. Al contrario: cuanto más entiendes, mejores decisiones puedes tomar y mejores instrucciones puedes dar. Pero la barrera de entrada ha cambiado muchísimo.
Hace unos años, una idea como esta probablemente se habría quedado en una libreta porque desarrollarla habría requerido contratar a varias personas o dedicar años a aprender diferentes disciplinas. Hoy puedo sentarme delante del ordenador, explicar una idea, discutirla, probarla, equivocarme, corregirla y seguir avanzando.
Y quizá esa sea la mayor conclusión de estos ocho meses.
La IA no ha hecho que deje de ser necesario pensar. Ha hecho que pensar bien sea todavía más importante.
Porque al final Codex puede encargarse del código, pero alguien tiene que decidir qué merece la pena construir.
.png)
0 Comentarios