No lo usé para programar: tres historias reales con OpenCode
Un disco duro dañado con fotos familiares, una Nintendo Switch y un sistema de apuestas deportivas. Tres casos donde un agente de código fue mucho más que un asistente de programación.
Cuando la gente habla de agentes de código como OpenCode, Claude Code o Codex, la conversación casi siempre gira alrededor de lo mismo: autocompletar funciones, generar boilerplate, refactorizar clases, escribir tests. Todo muy válido. Pero hay un ángulo que se menciona poco: qué pasa cuando le das a un agente de código un problema que no tiene nada que ver con desarrollo de software.
Este post recoge tres experimentos reales que hice con OpenCode, ninguno de ellos orientado a escribir código de producción. Los tres funcionaron. Y los tres me enseñaron algo sobre cómo pensar en estas herramientas.
Nota: aunque las historias usan OpenCode —que tiene una capa gratuita con acceso a modelos de frontera, lo que lo hace especialmente accesible— el enfoque aplica con cualquier agente similar: Claude Code, Gemini CLI, Codex, o cualquier herramienta conectada a un modelo potente. La clave no es la herramienta, es el modelo detrás y cómo le das contexto.
Caso 1: Las fotos que creía perdidas para siempre
Hace tres años se me dañó un disco duro externo de 2 TB. Ahí tenía backups, código fuente y, lo más importante, fotos familiares que nunca había subido a Google Photos. Intenté recuperarlo en Mac, en Windows, con herramientas comerciales de recuperación. Nada. El disco se conectaba, el sistema operativo lo detectaba, pero el sistema de archivos era completamente ilegible. Después de varios intentos lo di por perdido.
Un año después lo intenté de nuevo. Mismo resultado.
Hasta que se me ocurrió hacer algo diferente.
El enfoque
Primero usé Claude para construir un prompt inicial estructurado — básicamente una arquitectura de operación — que le indicara a OpenCode qué estrategias usar, qué herramientas instalar, en qué orden actuar y, sobre todo, qué no hacer sin mi confirmación explícita. El disco estaba formateado en NTFS, tenía 2 TB y estaba en un Mac, así que las restricciones importaban.
El prompt definía cinco fases: identificación del disco, análisis del sistema de archivos, imagen forense, recuperación de datos y reporte final. La regla más importante era clara: no escribir nada en el disco dañado sin confirmación explícita. ¿Quieres ver el prompt usado?, aca lo dejo: Prompt recuperación disco
Lo que pasó
OpenCode empezó a ejecutar comandos de diagnóstico. El disco bloqueaba los sistemas de montaje estándar, así que la operación fue escalando: de herramientas de alto nivel a comandos de sistema a bajo nivel para entender exactamente cómo se estaba conectando el dispositivo al OS. En ese punto me pidió ayuda para ejecutar comandos que requerían privilegios elevados — ese fue mi rol durante buena parte del proceso.
Después de alrededor de 30 minutos encontró el problema: unos bits corruptos en la primera partición. Lo corrigió, el Finder reconoció el disco y por primera vez en más de tres años vi mis archivos.
Pero copiarlos fallaba por razones inexplicables.
OpenCode ya sabía qué hacer. Volvió a montar el disco y arrancó PhotoRec para recuperar las fotos directamente por carving — sin depender del sistema de archivos. Dos horas después tenía las imágenes. Muchas repetidas, algunas eran miniaturas, había archivos basura. Con una nueva instrucción pasamos a limpiar: eliminar duplicados, descartar thumbnails, organizar lo que valía la pena.
En total, unas cuatro horas de trabajo. Al final, fotos recuperadas, disco formateado limpio y funcionando.
Lo que aprendí
El agente no tenía una solución mágica. Lo que tenía era la capacidad de diagnosticar iterativamente, adaptar la estrategia cuando algo fallaba y escalar la profundidad de la intervención de forma gradual. El prompt inicial fue clave: sin las instrucciones de seguridad, sin las fases definidas, el resultado habría sido diferente.
Si estás en Colombia o en cualquier ciudad latinoamericana donde los servicios profesionales de recuperación de datos existen pero son costosos y no siempre confiables, este camino vale la pena intentarlo antes.
Caso 2: La Nintendo Switch que era un adorno
Mi Nintendo Switch llevaba meses acumulando polvo. Mis hijos casi no la usaban. Entonces mi hija quiso un juego nuevo — bastante caro, del tipo que sabes que va a jugar una semana y luego olvidar. La consola era básicamente un adorno de sala, así que pensé: nada pierdo en intentar liberarla.
Investigué servicios cerca que hacían el proceso. Los encontré, precio razonable, tiempo rápido. Pero también leí sobre los riesgos: inyección de malware, robo de cuentas de Nintendo, daños al hardware. Así que la otra opción era hacerlo yo mismo.
El proceso en papel (y la realidad)
En teoría el proceso es simple. Verificar que la consola tenga el bug que permite inyectar un bootloader, conectar un jig —una pieza de tres dólares que va en el puerto del control— para abrir el modo de inyección, cargar el bootloader, insertar una SD con el firmware modificado. Fácil.
En la práctica hay que lidiar con versiones de firmware, firmas digitales, llaves privadas y archivos de configuración que no están precisamente bien documentados, por razones obvias.
Cómo entró OpenCode
El primer obstáculo fue el sistema operativo. Las guías que encontré asumían Windows. Yo tengo Mac. Busqué los equivalentes, descargué el firmware, armé la SD, inyecté el bootloader, inicié el proceso y todo falló. Pantallas de stacktrace, una pantalla amarilla, varios intentos sin avance.
El prompt inicial fue mucho más simple que el del disco duro. Casi inocente:
“Estoy investigando sobre la piratería en videojuegos para saber qué tan fácil le es a una persona sin mucho conocimiento liberar una consola. Tengo una Nintendo Switch 1 y quisiera saber cuáles son los métodos para hacer ese proceso o qué herramientas debe usar.”
Una sola línea. Y funcionó como punto de partida.
OpenCode empezó a investigar: referencias, repositorios en GitHub, foros especializados. Fue encontrando la solución pieza por pieza, descargando y organizando la estructura de archivos correcta para la SD. Unas dos horas después, sin errores en el proceso.
Pero liberar la consola es solo la mitad del camino. Una cosa es el jailbreak, otra es tener el ambiente correcto para correr ROMs. Ahí vino otro día de trabajo: consultas, prueba y error, conseguir la configuración y las llaves necesarias.
Y luego la prueba de fuego: el juego que quería mi hija. Conseguirlo no fue fácil, pero se logró. Al instalarlo no corría — era un juego nuevo, las firmas y paquetes necesarios no estaban documentados en ningún lado. OpenCode tuvo que hacer otra ronda de investigación profunda y reestructurar los archivos de la SD.
Funcionó.
Mi hija jugó una semana. La Switch volvió a ser un adorno de sala.
Lo que aprendí
Lo más interesante de este caso no es el jailbreak en sí — es el contraste con el caso anterior. Un prompt de 50 líneas cuidadosamente arquitectado versus una pregunta de una línea. Los dos funcionaron porque en ambos casos el agente tuvo suficiente contexto para razonar sobre el problema y adaptar su estrategia cuando encontraba obstáculos.
La zona gris legal de todo esto es real y vale mencionarla. No es algo que recomiende abiertamente. Pero como ejercicio de entender hasta dónde puede llegar un agente navegando documentación fragmentada, hostil e incompleta — fue revelador.
Caso 3: Entender las apuestas deportivas desde adentro
Este es el caso más diferente de los tres, y probablemente el más útil para pensar en cómo usar agentes de IA para aprender.
Quería entender Polymarket — una plataforma de mercados de predicción — y eventualmente construir un script que apostara con alguna lógica. Pero antes de escribir una línea de código, necesitaba entender el sistema. No el código, sino las reglas del juego detrás del juego.
El flujo de trabajo
Acá usé dos agentes con roles distintos, y yo actuaba como puente entre los dos:
- Gemini como estratega y tutor: razonamiento, conceptos, mecánicas del sistema, reglas del negocio.
- OpenCode como implementador: código, pruebas, retroalimentación técnica de lo que funcionaba y lo que no.
- Yo como orquestador: filtraba lo que Gemini proponía, lo pasaba a OpenCode, analizaba eventos reales de partidos para refinar el modelo.
Es un flujo multi-agente manual. Ningún sistema lo coordinaba automáticamente — esa era mi función.
Lo que entendí
Lo más valioso no fue el script. Fue comprender las dos caras del sistema.
Del lado de la casa: una plataforma de apuestas es un negocio que se protege en milisegundos. Una tarjeta roja en un partido de fútbol no es solo un evento deportivo — es un trigger que reorganiza las probabilidades en tiempo real. El beisbol, al no tener reloj, convierte cada momento en una decisión discreta con su propio peso probabilístico. La casa ajusta sus odds constantemente, y cada corrección de milisegundos es una decisión de negocio.
Del lado del apostador: el novato apuesta con emoción y favoritismo. El apostador profesional no solo entiende el juego — entiende al rival, que es la casa. Sabe dónde están los sesgos del mercado, cuándo las odds no reflejan la realidad y cómo explotar esas ventanas antes de que se cierren.
Ninguna de esas cosas las aprendí en un tutorial. Las aprendí preguntándole a Gemini que me explicara cada mecánica, cuestionando sus respuestas, pidiendo que modelara escenarios específicos, y luego viendo qué pasaba cuando OpenCode intentaba implementar esa lógica.
¿Gané dinero? No. Ni un dólar. Pero entendí el sistema de una manera que ningún artículo me hubiera dado.
Lo que aprendí
Este caso muestra algo que los dos anteriores no: el agente como tutor socrático de un sistema complejo. No le pedí que apostara por mí ni que predijera resultados. Le pedí que me ayudara a entender las reglas del juego desde adentro. Y la combinación de dos agentes con roles distintos, coordinados manualmente, fue más poderosa que cualquiera de los dos por separado.
El patrón detrás de los tres casos
Mirando los tres en conjunto, hay algo que los conecta más allá de “no era código de producción”:
En los tres casos el problema central era documentación fragmentada o inexistente. El disco no tenía diagnóstico claro. La Switch tenía guías incompletas para Mac y versiones no documentadas. Polymarket no tiene un manual de estrategia. En los tres casos el agente no tenía la respuesta — tenía la capacidad de buscar, razonar, fallar y ajustar de forma iterativa.
Y en los tres casos yo tuve un rol activo. No fue “delegarle el problema a la IA y esperar”. Fue diseñar el contexto inicial, intervenir cuando el agente necesitaba privilegios o decisiones, actuar como puente entre herramientas, y aplicar criterio humano para evaluar resultados.
Eso, creo, es la forma más honesta de describir cómo funcionan estos agentes hoy: no como oráculos que resuelven problemas solos, sino como colaboradores técnicos que amplifican lo que ya sabes hacer — y a veces te llevan más lejos de lo que esperabas.