Aunque tuve que corregir algunos errores de sintaxis, al final chatgpt escribió esto, incluyendo los comentarios explicativos:

https://www.gambas-it.org/wiki/index.php...rawingArea

---

Esto es impresionante (incluso los comentarios explicativos son de chatgpt):

https://www.gambas-it.org/wiki/index.php...i_dedicati

Mejora dia a dia pero no deja de depender de un programador experimentado. Y con las correcciones que hacemos, aprende mas. O sea, nos usa y encima le pagamos usd20/mes.

Hola
El otro día me atreví a crear programas gambas con la IA.
Estuve probando la IA de Gogle, Microsoft, DeepSeek, y CHATGPT.
La mayor frustración fue que después de 3 horas corrigiendo a las IAs, al día siguiente no sabía nada de lo que le había enseñado.
Todas funcionan de la misma manera, olvidan todo lo enseñado en la siguiente sesión. Debes hacer un resumen de lo enseñado ese día para luego recordárselo al día siguiente.

Al final me quede con la de Google, por diferentes motivos, en algún caso como ChatGPT te limitaba el tiempo por sesión, la DeepSeek me hacía procedimientos en el programa que yo no había pedido. Que cada uno pruebe.


Hice dos pruebas: uno que pintaba formas geométricas, y otro era una libreta de direcciones sencilla.

Por si queréis probarlo os doy los pasos:

Indicar la sintaxis que tuve que guardar el día anterior:

----
Aquí tiene el resumen de las precisiones y correcciones de sintaxis que ha señalado durante la sesión:

    Uso directo de Draw.Begin en el control:

        Corrección: En lugar de dibujar sobre un objeto Picture en memoria (como yo había sugerido), indicó que se debe iniciar y finalizar el dibujo directamente sobre el control DrawingArea:
        code Gambas

    Draw.Begin(DrawingArea1)
    '...
    Draw.End()


Sintaxis exacta para definir el color (Color.RGB):

    Corrección: Precisó que para asignar el color de forma estricta en Gambas se debe utilizar la llamada a la clase Color:
    code Gambas

Draw.Foreground = Color.RGB(r, g, b)
----

Ahora le pido que haga el programa:

Petición Inicial: Crear un programa con un área de dibujo (DrawingArea) y un menú desplegable con las opciones: Líneas, Círculos, Rectángulos, Elipses, Borrar y Salir.

    Restricción de Interfaz (Sin atajos): Especificaste que no querías "adelantos de teclado" (eliminar el uso del símbolo & que genera subrayados automáticos).

    Corrección y Ajuste de Separadores: Precisaste la sintaxis exacta del menú separador (Text = "-") y, acto seguido, solicitaste eliminar por completo los separadores para dejar un menú continuo.

    Multiplicación de Elementos: Pediste modificar el programa para que, en lugar de una sola figura, se dibujaran exactamente 10 líneas, 10 círculos, 10 rectángulos y 10 elipses.

    Componente Aleatorio: Solicitaste que esas 10 figuras tuvieran dimensiones aleatorias cada vez que se seleccionaran.

    Variedad Cromática: Añadiste el requisito de que cada una de las 10 figuras tuviera un color diferente.

    Relleno Sólido: Como toque final para este programa, pediste que las figuras geométricas cerradas estuvieran completamente rellenas.

------- 

El segundo programa es una libreta de direcciones sencilla.
Continuando con la sesión , con la sintaxis de tu sesión.

  Petición Inicial: Diseñar un programa nuevo que funcionara como una agenda o libreta de direcciones simple (campos para Nombre, Teléfono, Email, botones de control y una lista visual).

    Persistencia de Datos: Pediste añadir un menú para Guardar y Leer los contactos en el disco duro para no perderlos al cerrar la aplicación.

    Ampliación y Motor de Búsqueda: Solicitaste añadir las opciones de Acerca y Salir al menú, además de la funcionalidad clave de poder buscar un nombre (que terminamos implementando como un filtro inteligente en tiempo real).

------



Conclusión:
La IA es una herramienta muy útil, no es la panacea para programar, pero te ahorra mucho tiempo.
Debes tener en cuenta  que tienes que tener conocimientos en el lenguaje de programación, la IA se equivoca bastante, pero aprende rápido.
No olvides que todas las cosas que le enseñas las olvida de una sesión a otra, debes guardar el resumen de lo que has hecho, y al día siguiente cargarla al inicio de sesión.
Aconsejo que lo probéis  es de lo mas curioso, y seguro que lo emplearéis en vuestros programas.

Un saludo
SETA43

Hola gente, les comparto mi experiencia

IA en proyectos utilizando Gambas: no es el modelo, es el contrato

1. El punto de partida

Leyendo el hilo veo un patrón repetido: se abre el chat, se pide «hacéme una función que haga X en Gambas», se pega el resultado en el IDE, no compila o compila y hace cualquier cosa, y la conclusión es «la IA no sirve para Gambas».

Es una conclusión razonable a partir de esa evidencia, pero la evidencia está sesgada por el método. Lo que se está probando ahí no es la capacidad del modelo: es el peor modo de uso posible, el modo oráculo. Se le pide a un sistema estadístico que adivine, sin contexto, sin restricciones y sin verificación, y después se mide el resultado contra un proyecto real.

Mi experiencia después de bastantes meses de desarrollo sostenido es distinta, pero no porque haya encontrado un modelo mágico. Es porque dejé de pedir código y empecé a construir un contrato de trabajo.

2. Por qué Gambas es un caso especialmente hostil

Antes del método conviene entender el problema de fondo, porque explica el 80 % de los errores que están reportando.

Un LLM aprende de lo que abunda. De Python, JavaScript o C# hay millones de líneas públicas. De Gambas hay: la wiki oficial, el código del propio IDE, unos cuantos repos y este foro. Es un corpus pequeño.

Peor todavía: es un corpus pequeño rodeado de un corpus enorme y parecido. La sintaxis de Gambas se parece lo suficiente a Visual Basic y VB.NET como para que el modelo, ante una duda, complete con VB. De ahí salen la mayoría de los horrores que se ven:

Código:

Try ... Finally

(no existe en Gambas),

Código:

On Error Resume Next

colecciones con métodos de .NET, firmas inventadas de componentes.

O sea: el modelo no falla al azar. Falla en una dirección predecible. Y todo lo que falla de forma predecible se puede acorralar con reglas.

3. El cambio de enfoque: del prompt al documento de reglas

Lo que cambió todo en mi caso fue dejar de tratar cada consulta como un evento aislado y empezar a mantener un documento de condiciones del proyecto, que se carga como contexto permanente en cada sesión de trabajo. No es un prompt: es documentación de proyecto que además sirve como prompt.

El documento tiene el stack, el sistema operativo objetivo, las convenciones de comentarios y encabezados de función, la forma de pedir parches… y sobre todo dos capas de conocimiento acumulado que son el corazón del asunto: las RC y las SC.

3.1 RC — Reglas Críticas

Una RC es una trampa que ya me costó tiempo real. No es teoría, no es estilo: es la cicatriz de un bug, redactada de forma que no vuelva a pasar.

Formato: código estable, título en imperativo, explicación del síntoma, forma correcta.

Ejemplo real (lo comparto entero porque es puro Gambas y le sirve a cualquiera):

RC-GM-01 — `TINYINT(1)` NO ES INTEGER
MySQL devuelve `TINYINT(1)` como `Boolean` en Gambas.
NUNCA: `CInt(resultado["campo"]) = 1`
SIEMPRE: `resultado["campo"] = True`

Otro:

RC-GM-02 — `Try` NO INTERRUMPE LA EJECUCIÓN
Si un `Try` falla silenciosamente, el código sigue con datos vacíos o incorrectos.
Verificar siempre con `If Error Then` inmediatamente después.

Ese segundo caso es interesante porque el error no es del modelo: es mío, es un rasgo del lenguaje que se me escapaba a mí también. La regla protege al humano y a la IA por igual. Hoy tengo catorce RC de Gambas y doce de XSLT. Cada una nació de una sesión de depuración que no quiero repetir.

Lo importante: una RC se gana, no se inventa. Si escribo reglas preventivas de todo lo imaginable, el documento se infla, pierde autoridad y el modelo empieza a diluir la atención entre cincuenta reglas tibias en vez de doce reglas duras.

3.2 SC — Soluciones Canónicas

Una SC es distinta. No es una trampa: es una decisión de diseño ya tomada y cerrada.

El problema que resuelve es específico del trabajo con IA y es más sutil que el de los errores de sintaxis. Un modelo no tiene memoria entre sesiones y, cada vez que ve un problema, propone la solución más común de su entrenamiento. Si hace tres meses decidí que en este proyecto las comillas dentro de un string se construyen siempre con `Chr(34)` y nunca con comillas duplicadas, sin una SC voy a tener que discutir esa decisión otra vez. Y otra. Y en la cuarta discusión voy a ceder por cansancio y el proyecto va a quedar inconsistente.

La SC dice, literalmente: esto está cerrado, no reabrir el debate, aplicar directamente.

SC-01 — Caracteres especiales en strings
Usar `Chr(34)` para comillas dobles y `Chr(10)` para salto de línea. Nunca literales duplicados dentro del string.

Otras SC del proyecto cubren el tratamiento de UTF-8 de punta a punta (por qué `String.Mid()` y no `Mid()`, que opera en bytes y parte una eñe al medio), la centralización de constantes de interfaz en un módulo único, y el patrón para insertar y seleccionar texto en el `TextEditor` capturando posiciones en lugar de calcularlas.

En resumen: las RC evitan que el código se rompa. Las SC evitan que el proyecto se vuelva incoherente. Son dos tipos de deuda técnica distintos y necesitan tratamientos distintos.

4. Las tres cláusulas que más rinden

Si alguien quiere probar el enfoque sin armar un documento completo, estas tres solas ya cambian bastante el resultado:

• a) Prohibición explícita de inventar. «Ante cualquier duda sobre sintaxis o componentes, consultar la documentación oficial antes de responder. No inventar ni suponer nada; todo el código debe tener base documental.» Esto ataca directo la deriva hacia VB.
  
• b) Obligación de declarar la incertidumbre. «Si una firma o componente no se puede verificar en la documentación oficial, decirlo explícitamente y proponer un mini-test antes de comprometer código en el proyecto.» Un modelo que dice «no puedo confirmar esta firma, probemos esto de seis líneas primero» vale muchísimo más que uno que produce cien líneas plausibles. El mini-test es la pieza clave: convierte la duda en un experimento barato en vez de en un bug caro.
  
• c) Sistema de coordenadas para los parches. Nada de «acá te va la función completa». El formato es: en el archivo X, dentro de la función Y, en el apartado N, bloque exacto a reemplazar y su reemplazo. Esto obliga a razonar sobre el código que existe, no sobre el que el modelo imagina, y hace que los cambios sean revisables de un vistazo.
  

Como complemento, cada función lleva encabezado normalizado (propósito, parámetros, retorno) y apartados numerados internos. Eso no es cosmética: es lo que hace posible el punto c y lo que permite volver a una función seis meses después.

5. El ciclo de trabajo

El modelo mental que me funciona no es «asistente que escribe código». Es par de programación con un colaborador rapidísimo, con una memoria de largo plazo defectuosa y una tendencia conocida a la confabulación. Eso define los roles:

1. Yo defino el problema y la arquitectura. La IA no decide la estructura del proyecto.
   
2. La IA propone implementación, dentro de las RC y las SC, con base documental.
   
3. Si hay algo no verificable, mini-test primero. Nunca al proyecto directo.
   
4. Compilo yo, pruebo yo. En Gambas no alcanza con guardar: Proyecto → Limpiar, Proyecto → Compilar. Y probar en datos reales, no en el caso feliz.
   
5. Cuando algo falla de una forma nueva, no se corrige y listo: se escribe la RC. Ese paso es el que hace que el sistema mejore en vez de estancarse.
   

El punto 5 es el que separa esto de «usar ChatGPT». El documento de condiciones es un activo que se capitaliza: cada bug pagado una vez se convierte en una línea que evita pagarlo diez veces.

6. Sobre la elección del modelo

No quiero que esto suene a publicidad, así que lo pongo en términos de requisitos funcionales. Para este modo de trabajo el modelo necesita:

• Ventana de contexto grande, para sostener el documento de reglas más varios archivos   del proyecto sin olvidarse de la primera mitad.
  
• Buen seguimiento de instrucciones negativas («nunca hagas X»), que es donde más varían los modelos entre sí.
  
• Capacidad de decir que no sabe. Un modelo que nunca duda es inutilizable acá.
  

Los modelos de gama alta actuales son los ideales, porque cumplen razonablemente los tres puntos; los gratuitos y las versiones reducidas, mucho menos: son justamente los que rellenan huecos con VB. Buena parte de las quejas del hilo probablemente se expliquen por ahí, sumado al modo oráculo.

Dicho eso: un buen modelo sin marco de trabajo rinde peor que un modelo mediano con marco. Si hay que invertir en un solo lado, invertir en el documento.

7. Qué no resuelve

Para no decir huevadas:

• No reemplaza saber Gambas. Al contrario: hace falta saber bastante (o al menos lo suficiente) para detectar cuándo la respuesta es plausible pero falsa. El que no sabe, no puede auditar.
  
• No sirve para diseñar la arquitectura del proyecto. Sirve para implementarla (*).
  
• Los componentes menos documentados siguen siendo terreno resbaladizo, incluso con   documentación oficial a la vista. `TextEditor` de `gb.form.editor` me dio varios dolores   de cabeza justamente por eso: la propia wiki advierte que puede cambiar sin aviso.
  
• Hay un costo de entrada real. El documento no se escribe en una tarde; se sedimenta.
  

(*) Sobre la etapa de discusión previa. El punto se puede leer mal, así que lo preciso: como interlocutor de diseño la IA sí sirve, y bastante. Mi política de trabajo es que ninguna funcionalidad se implementa sin una etapa previa explícita de debate, sin escribir ni una sola línea de código. Ahí planteo el problema, se evalúan los caminos posibles, y sobre todo se analiza cómo cada opción impacta en el resto del proyecto: qué módulos toca, qué se rompe, qué decisiones anteriores condiciona, qué deuda genera. Recién cuando el camino está elegido y entendido se pasa a implementar.

El valor de esa etapa no está en que la IA «decida bien», sino en que obliga a explicitar el razonamiento y devuelve objeciones y alternativas que uno no había considerado. Es lo más parecido a discutir con un colega que conoce el proyecto y no tiene apuro. Pero la decisión final es mía y queda registrada: si el camino elegido cierra una discusión de diseño, se escribe como SC y no se vuelve a abrir.

Saltear esta etapa es, en mi experiencia, la otra gran causa de frustración —además del modo oráculo—: si uno pide implementación directa, obtiene código que funciona aisladamente y desordena todo lo demás.

8. Cierre

Mi conclusión después de este recorrido es que la pregunta «¿sirve la IA para Gambas?» está mal planteada. La pregunta útil es: ¿qué infraestructura hay que montar alrededor para que sirva? Y la respuesta, en mi caso, fue un documento de condiciones vivo, con reglas críticas ganadas a fuerza de bugs y decisiones canónicas cerradas, más una disciplina de verificación que no delega la compilación ni la prueba.

El efecto colateral que no esperaba: ese documento es hoy la mejor documentación técnica que tiene mi proyecto. Sirve para la IA, sí, pero sobre todo me sirve a mí cuando vuelvo a un módulo después de tres meses.

Alberto — desarrollo de gbpublisher

Muy buen aporte, Alberto. Gracias.

Hola,

Después de leer todos los mensajes de este tema sobre escribir código Gambas con una IA, comparto con ustedes una pequeña experiencia al respecto.

En la actualidad, ninguna IA (o mejor dicho, hablemos de un modelo de IA o LLM) conoce suficientemente el lenguaje Gambas para escribir código Gambas correcto.
De hecho, se necesitan toneladas de datos e información sobre un lenguaje para entrenar un modelo de IA y, lamentablemente, eso todavía no ocurre con Gambas: hay demasiado pocos datos o ejemplos. La documentación existe, pero en algunos casos es demasiado escueta.

Todo esto hace que los modelos de IA no sean buenos, y al final se obtiene una mezcla de muchos otros lenguajes en lugar de tener código Gambas.


Aquí es donde se pueden mejorar las cosas.

En mi caso, uso un modelo de IA local, por lo que nada sale de casa y mi IA ni siquiera puede salir a Internet (yo se lo prohíbo).

También hay que entender que un modelo de IA, una vez entrenado con datos, queda fijado en el tiempo; esto significa que sus conocimientos se detienen en la fecha de finalización del entrenamiento del modelo. En el caso de Gambas, los datos de entrenamiento de los modelos generalmente se detienen a mediados de 2024 o, como mucho, a principios de 2025.

Por lo tanto, en mi caso, mi modelo de IA local ni siquiera puede salir a Internet para obtener información reciente sobre Gambas.

La solución que encontré fue desarrollar (gracias a una IA) lo que se llama un 'servidor MCP RAG'.
Este servidor MCP RAG es en realidad una gran base de datos SQLite3 + FTS5 (módulo para búsqueda semántica), en la que se ha inyectado la totalidad de la documentación oficial de Gambas3.
Además, este servidor MCP RAG expone una lista de herramientas dedicadas a Gambas, por ejemplo:
- Proporcionar los 'prompts' al modelo de IA para: experto en Gambas, experto en BD Gambas, experto en auditoría de código Gambas, etc.
- Realizar una búsqueda en la documentación de Gambas
- Obtener la lista de todos los comandos de Gambas
- Cómo compilar un proyecto de Gambas
- Cómo crear un script de Gambas
- Buscar código en proyectos reales de Gambas, clasificados por tema.
- Cómo crear una estructura vacía de un proyecto de Gambas: proyecto CLI, gráfico, web
- Etc.

Por supuesto, este servidor MCP RAG es local y sirve como una gran enciclopedia para todo lo relacionado con Gambas.

A continuación, mi configuración para desarrollar en Gambas con una IA local.

Por un lado: lo que hace funcionar mi IA local:

- Un MacBook M4 Pro + 48 GB de RAM compartida
- LM Studio + Qwen3.8-27B (modelo de IA)

Por otro lado:

- Un PC con Linux
- Visual Code + extensión 'Cline' ('Cline' es un agente de IA que se conecta a LM Studio en mi MacBook)
- El agente 'Cline' conectado a mi servidor MCP RAG

Conclusión:

- Una IA local es mucho menos potente que ChatGPT, Claude, etc., pero no me cuesta nada; puede funcionar durante horas sin problema y ningún dato sale de casa.

- El hecho de conectar mi IA local a mi servidor MCP RAG a través de mi agente 'Cline' permite que mi modelo de IA esté informado sobre toda la información relacionada con Gambas y mucho más.

- Desde que mi servidor MCP RAG funciona, mi IA ha dejado de escribir cualquier cosa y ahora se vuelve mucho más relevante.

- Aunque debo ser honesto con ustedes, sigo metiendo mano al embrollo generado por mi IA porque todavía no es perfecto del todo.

- Una última cosa: a menudo uso mi IA local para que me explique conceptos de programación, por ejemplo cómo usar la API de PayPal, cuáles son los estándares de la industria para implementar tal o cual tecnología, y suele ser muy pertinente.
A partir de ahí, basándome en esas explicaciones, me lanzo a implementar esos conceptos MANUALMENTE (porque me encanta programar en Gambas).

Eso es todo por esta pequeña experiencia.
Olivier

Hola, gracias a todos por sus aportes, veo que hay un interés alto en este tema.
Tanto lo que plantea Alberto como lo Que plantea Oliver.
Son dos caminos muy interesantes, yo tengo ganas de comprarme una tarjeta de tensores usada y ponerme a entrenar un LLM para aprender para lograr algo como lo de Oliver.
Lo de Alberto es un afinado interesante que promete también.
Pero a todos estos métodos, incluso si se logra un codigo gambas perfecto, tienen un inconveniente y este es que funciona solo para una persona, para el que entreno el modelo o creo la estructura.
A mi me interesa algo mas global, no se como se podria hacer pero lo realmente util seria:
- Repartir el entrenamiento entre varios actores.
- Crear un LLM opensource en algun alojamiento al que puedan acceder todos los que programen en gambas.

No se si podría ser algo híbrido entre un LLM existente + un afinado exclusivo para gambas.

¿No creen que seria mas efectivo trabajar en equipo para mejorar el modelo para gambas?
Yo uso de vez en cuando https://duck.ai que no produce los mejores resultados la verdad pero voy a explorar una linea para intentar mejorar el código producido que consiste en poner en un repo gitlab un archivo con los detalles de gambas y luego poner un enlace antes de hacer la pregunta (escribir el prompt).
Si el método funciona podríamos mejorarlo pasando por el foro mismo esas reglas, como las de Alberto por ejemplo, y luego ponerlas en el archivo en el repo.
¿Que les parece?