OpenAI refuerza ChatGPT en lenguajes de programación menos usados: COBOL y SQLite en la mira

OpenAI informó que está trabajando en mejorar ChatGPT en lenguajes de programación de bajos recursos, es decir, aquellos con escasa representación en los datos de entrenamiento de los modelos y en las comunidades de desarrollo. El anuncio menciona de forma concreta nuevas evaluaciones en tres frentes: ingeniería de software, SQLite y migración de COBOL.

Qué se anunció

El hecho verificable es acotado: la compañía comunicó un avance en el desempeño de ChatGPT sobre lenguajes poco representados y presentó un conjunto de evaluaciones orientadas a medir ese desempeño en tareas de software, en el uso de SQLite y en procesos de migración de COBOL. La información difundida no detalla el alcance técnico de cada prueba ni los resultados obtenidos.

Los tres frentes mencionados

• Ingeniería de software: pruebas generales sobre tareas de desarrollo, el terreno donde se suele medir la utilidad práctica de un asistente de código.
• SQLite: un motor de base de datos ligero, muy extendido en aplicaciones móviles, sistemas embebidos y herramientas de escritorio.
• Migración de COBOL: el escenario típico de modernización de sistemas heredados, especialmente costoso para organizaciones con décadas de código acumulado.

La lectura de que estos tres frentes apuntan a un mismo objetivo —hacer que el modelo sea útil fuera de los lenguajes dominantes como Python o JavaScript— es análisis de este medio, no un planteamiento textual de la empresa.

Por qué importa

La mayor parte de la innovación en asistentes de código se ha concentrado en los lenguajes más populares, porque son los que abundan en repositorios públicos y en las preguntas de los foros. Ese sesgo tiene una consecuencia práctica: el modelo funciona razonablemente bien en el stack moderno y falla con más frecuencia en el código que sostiene la operación real de muchas empresas.

COBOL es el caso más visible. Durante décadas ha sido la columna vertebral de la banca, los seguros y los sistemas de nómina y facturación. Cada vez quedan menos especialistas disponibles para mantenerlo, y buena parte del conocimiento está en personas cercanas al retiro. Cualquier herramienta que reduzca la fricción para entender, documentar o migrar ese código tiene un valor económico directo.

SQLite, por su parte, aparece en lugares poco glamorosos pero masivos: aplicaciones móviles, terminales de punto de venta,软件 de escritorio y prototipos que luego crecen. Un asistente que entienda bien ese motor puede ahorrar horas de depuración en proyectos pequeños que no tienen equipo especializado.

Implicaciones para PYMES de América Latina

Modernización de sistemas heredados

Para empresas de la región que proveen servicios a bancos, aseguradoras o entidades públicas, la migración de COBOL sigue siendo un negocio recurrente y difícil de escalar por falta de personal. Una mejora en la capacidad del modelo para interpretar y transformar ese código podría traducirse en diagnósticos más rápidos y propuestas de migración mejor documentadas. El ahorro vendría de la fase de análisis, no necesariamente de la reescritura completa.

Herramientas ligeras y datos locales

Muchas PYMES construyen soluciones sobre SQLite porque no requieren infraestructura de base de datos dedicada. Un soporte más sólido en ese terreno reduce la dependencia de un único desarrollador experimentado y facilita que equipos pequeños mantengan sus propias aplicaciones.

Un puente, no un reemplazo

La implicación más realista es la de asistencia: generar explicaciones, proponer pruebas, señalar inconsistencias y traducir fragmentos entre lenguajes. En entornos con presupuesto limitado, ese apoyo puede ser más valioso que intentar automatizar por completo una migración crítica.

Limitaciones y riesgos

• Sin cifras públicas: la información difundida no incluye métricas de mejora ni comparaciones con versiones anteriores, por lo que no es posible dimensionar el avance.
• Evaluaciones no equivale a producción: superar una prueba diseñada por el propio proveedor no garantiza un comportamiento correcto en el código específico de cada empresa.
• Código plausible pero incorrecto: en lenguajes heredados, un fragmento sintácticamente válido puede introducir errores silenciosos de lógica o de manejo de datos.
• Riesgo de dependencia: apoyarse en un único proveedor para tareas críticas de mantenimiento crea una vulnerabilidad a mediano plazo.
• Condiciones de acceso inciertas: no se especifica disponibilidad por país, nivel de servicio ni idioma de soporte, factores relevantes para equipos en América Latina.

Qué observar de aquí en adelante

El anuncio debe leerse como una señal de dirección más que como un resultado consolidado. Vale la pena seguir tres cosas: si se publican resultados detallados de las evaluaciones, si aparecen casos de migración reales documentados y si el soporte llega a las versiones de los productos que usan las empresas pequeñas, no solo a los entornos empresariales. Mientras eso no ocurra, la recomendación práctica para una PYME es mantener revisión humana obligatoria sobre cualquier salida del modelo en código heredado.