Experimento de portabilidad del SDK de integración externa a Go con LLM

¡Hola a todos,

Después de diferentes pruebas de LLM, publico un portado del SDK (v0.11.0) para la creación de una integración externa en el lenguaje Go.

El enlace al proyecto se encuentra aquí: experimental-gladys-assistant-integration-sdk-go.

Para validar mi SDK, he escrito pruebas y creado un ejemplo a partir del proyecto de @prohand sobre la calidad del aire, ya que es bastante simple.

Historia del portado

Quería probar las capacidades de Cline con mi suscripción Cline Pass haciendo pruebas con varios LLM, para encontrar la mejor estrategia de desarrollo.

Primer portado en Python

Comencé con un portado en Python usando Qwen 3.8 Max para establecer el plan del proyecto y realizar el análisis del SDK oficial en JS. Luego, utilicé Deepseek V4 Pro para el desarrollo.

El SDK en Python funcionaba, pero la imagen Docker de ejemplo (calidad del aire) —que es bastante simple— ocupaba 300 Mo de espacio de almacenamiento. Hay que almacenar Python y todas las dependencias del proyecto. Un tamaño así para un código tan pequeño es, en mi opinión, una herejía, y no es viable a largo plazo cuando se usan docenas de integraciones externas.

Nuevo portado en Go

Por lo tanto, volví a empezar desde cero con un lenguaje compilado, estable y muy utilizado. Mi elección fue Go por las razones mencionadas anteriormente, pero también porque está bien dominado por los LLM y es desarrollado por Google (una garantía de seriedad). Para información, Docker está escrito en Go.

Esta vez, utilicé únicamente un LLM económico para ver si era suficiente, y mi elección fue Deepseek V4 Flash. Lo utilicé tanto para el razonamiento como para la codificación.

Este modelo resultó ser suficiente. No es necesario tener un modelo grande como Fable o Kimi K3, ya que @pierre-gilles hizo un trabajo excelente con su README muy completo. Contiene todos los detalles técnicos para que un LLM, incluso « simple », pueda realizar un portado. Lo mismo ocurre con la integración externa gracias a su plantilla muy bien documentada.

Al final, ahora tengo un SDK y un ejemplo funcionales con una imagen Docker de menos de 19 Mo. Es, por lo tanto, muy ligero en comparación con los 169 Mo de la versión JS de @prohand. No hay nada sorprendente en esto: la versión JS requiere Node.js y sus dependencias, mientras que en mi caso, se trata de un simple ejecutable en una imagen basada en Alpine OS.

Conclusión

Tras mis pruebas, lo más importante sigue siendo la redacción de una buena definición del proyecto, tanto en los objetivos principales como en los aspectos técnicos, idealmente con la ayuda de un modelo como Qwen 3.8 Max / Fable / Opus. Una vez que el archivo README.md, AGENTS.md o CLAUDE.md está redactado y completo, se puede pasar a un modelo más ligero para la codificación. En mi caso, Deepseek V4 Flash fue suficiente, pero la versión Pro sigue siendo preferible si el código generado contiene demasiados errores o resulta demasiado complejo.

¿Y ahora?

No voy a mantener este proyecto: se trataba de una experimentación y no tendré tiempo de ocuparme de él junto a mis otros proyectos. Pueden retomarlo si lo desean, es completamente libre.

Espero que este post les interese y les ayude en sus futuros desarrollos.

3 Me gusta