Flant: cómo un desarrollador de Go convirtió Zed y Gemini en un agente de IA útil

Un desarrollador de Go de Flant describe un recorrido práctico que muchos equipos reconocerán: de la curiosidad por los plugins de IA y la decepción con ellos a un esquema de trabajo en el que el agente realmente libra al programador de parte de la rutina. La idea central del artículo es sencilla: un LLM por sí solo apenas mejora la productividad si tiene mal acceso al contexto del proyecto, una interfaz lenta y herramientas inadecuadas para el lenguaje concreto.

Primero, el autor pasó por un escenario típico de adopción temprana. En GoLand 2022 probó un plugin de IA con un modelo en la nube integrado, que ofrecía tres modos: autocompletado, chat y agente. Las sugerencias automáticas aceleraban algo el trabajo, pero a menudo fallaban por el contexto limitado. El chat dentro del IDE se convirtió pronto en una sincronización interminable del estado del proyecto: el modelo hacía suposiciones y el desarrollador perdía tiempo explicando. El modo agente sabía escribir y refactorizar código, pero demasiado a menudo exigía rehacerlo a mano, así que el ciclo «plantear la tarea, revisar, reescribir» resultaba más largo que trabajar normalmente sin IA.

La siguiente etapa ya incluyó acceso corporativo a varios modelos. El autor valoró las respuestas de GPT-4o como claramente mejores que las de GigaChat, pero eso no resolvió el problema principal. Cuando la empresa abrió el acceso mediante clave de API, probaron en el IDE plugins populares como Cline y Continue. El resultado volvió a ser flojo: la combinación de IDE, lógica de interfaz web y modelo externo iba lenta y el trabajo seguía siendo pesado.

El punto de inflexión fueron los agentes de terminal. OpenCode era popular entre sus colegas, pero el autor eligió Crush por su instalación más cómoda y porque la herramienta está escrita en Go. Ahí obtuvo por primera vez un beneficio real: el agente podía analizar el proyecto, leer archivos, escribir código y usar LSP y MCP.

Sin embargo, el agente de terminal tampoco fue la parada final. Para el trabajo diario con un repositorio Git y la base de código aún faltaba la comodidad de un editor. Por eso el autor pasó a Zed, un editor rápido escrito en Rust con panel de IA integrado, agente propio y compatibilidad con agentes externos mediante ACP.

En el artículo detalla cómo conectar Zed a un servicio LLM corporativo a través de Open-WebUI y una API compatible con OpenAI, elegir el modelo Gemini 3 Flash y configurar el perfil write con las herramientas necesarias: diagnostics, read_file, grep, list_directory, terminal, thinking y web_search. Destaca además un detalle práctico: la clave de API no se guarda en el archivo de configuración y se introduce manualmente desde la interfaz del editor.

La parte técnica más importante se refiere a Go y a la calidad del contexto. Con un ejemplo sencillo, el autor muestra que el grep integrado solo encuentra coincidencias de texto y lleva fácilmente al modelo a suposiciones erróneas si la consulta es vaga. Para que el agente trabaje más cerca de la semántica del código, conecta gopls en su modo experimental MCP.

Como el LSP normal de Zed está orientado por ahora a personas y no a agentes, hay que levantar un gopls-mcp aparte con sus propias variables de entorno y un tiempo de espera ampliado. A cambio, el agente obtiene herramientas de otra categoría: vista general del workspace, API de paquetes, búsqueda de símbolos, referencias a símbolos, renombrado seguro, diagnóstico e incluso comprobación de dependencias en busca de vulnerabilidades conocidas.

El artículo sirve como una útil guía para elegir un stack de AI coding. Primero hay que escoger un LLM que sepa trabajar en modo agente y resuelva bien tareas de programación; para una evaluación aproximada, el autor aconseja fijarse en el equilibrio entre calidad, precio, velocidad y tamaño de la ventana de contexto. Después, elegir el agente: importan la compatibilidad con el modelo, un conjunto razonable de herramientas integradas, soporte de MCP y, si hace falta, multiagente.

Solo entonces tiene sentido ocuparse de los prompts. Entre las técnicas que el autor considera realmente útiles están el role prompting, adjuntar contexto de forma explícita, la planificación paso a paso, el step-back prompting y el uso de ejemplos del código o de las pruebas existentes.

La conclusión principal del artículo es que la productividad del desarrollador no crece por tener «alguna IA» en el editor, sino por montar con precisión todo el circuito: un entorno rápido, un modelo adecuado, herramientas del lenguaje y disciplina al plantear las tareas. Cuando el agente ve el proyecto a través de LSP y MCP y no mediante una búsqueda ciega por líneas, y cuando se le han definido de antemano los roles, perfiles y contexto correctos, deja de ser un asistente ruidoso y empieza a ahorrar tiempo real en código, navegación y comprobaciones.