Flant : comment un développeur Go a transformé Zed et Gemini en un agent IA utile

Un développeur Go de Flant a décrit un parcours pratique familier à de nombreuses équipes : de la curiosité pour les plugins IA et la déception qu'ils suscitent à un schéma fonctionnel où un agent soulage réellement le développeur d'une partie de la routine. L'idée principale de l'article est simple : par elle-même, une LLM augmente à peine la productivité si elle a un accès médiocre au contexte du projet, une interface lente et des outils inadéquats pour un langage particulier. D'abord, l'auteur a traversé un scénario typique d'adoption précoce.

Dans GoLand 2022, il a essayé un plugin IA avec un modèle cloud intégré et en a obtenu trois modes : autocomplétion, chat et agent. L'autocomplétion a légèrement accéléré le travail mais commettait souvent des erreurs dues à un contexte limité. Le chat dans l'IDE s'est rapidement transformé en synchronisation infinie d'état : le modèle faisait des hypothèses, et le développeur passait du temps à clarifier.

Le mode agent pouvait écrire et refactoriser du code, mais exigeait très souvent une refonte manuelle, de sorte que le cycle « définir la tâche — vérifier — réécrire » s'avérait plus long que le travail régulier sans IA. L'étape suivante s'est déroulée avec un accès d'entreprise à plusieurs modèles. L'auteur a évalué la qualité des réponses de GPT-4o significativement plus élevée que celle de GigaChat, mais cela n'a pas résolu le problème principal.

Quand l'entreprise a ouvert l'accès par clé API, ils ont essayé des plugins populaires comme Cline et Continue dans l'IDE. Le résultat s'est avéré faible à nouveau : le couplage de l'IDE, de la logique d'interface web et du modèle externe ralentissait les choses, et le travail restait difficile. Les agents de terminal ont été le moment décisif.

OpenCode était populaire parmi les collègues, mais l'auteur a choisi Crush en raison d'une installation plus facile et du fait que l'outil est écrit en Go. C'est là qu'il a obtenu un vrai bénéfice pour la première fois : l'agent pouvait analyser le projet, lire des fichiers, écrire du code et utiliser LSP et MCP. Cependant, l'agent terminal n'était pas le point final.

Pour le travail quotidien avec un dépôt Git et une base de code, la commodité de l'éditeur manquait toujours. L'auteur a donc adopté Zed — un éditeur rapide basé sur Rust avec un panneau IA intégré, son propre agent et la prise en charge des agents externes via ACP. Dans l'article, il détaille comment connecter Zed à un service LLM d'entreprise via Open-WebUI et une API compatible OpenAI, choisir le modèle Gemini 3 Flash et configurer un profil write avec les outils nécessaires : diagnostics, read_file, grep, list_directory, terminal, thinking et web_search.

Un détail pratique est souligné séparément : la clé API n'est pas stockée dans le fichier de configuration et est saisie manuellement via l'interface de l'éditeur. La partie technique la plus importante concerne le langage Go et la qualité du contexte. L'auteur montre par un simple exemple que le grep intégré ne trouve que des correspondances textuelles et conduit facilement le modèle à des hypothèses incorrectes si la requête est formulée vaguement.

Pour faire fonctionner l'agent plus près de la sémantique du code, il connecte gopls en mode MCP expérimental. Puisque LSP régulier dans Zed est actuellement orienté vers les humains plutôt que vers les agents, il doit exécuter un gopls-mcp séparé avec ses propres variables d'environnement et un délai d'expiration augmenté. Mais après cela, l'agent obtient une classe différente d'outils : aperçu de l'espace de travail, API de paquets, recherche de symboles, références de symboles, renommage sûr, diagnostics et même vérification des dépendances contre les vulnérabilités connues.

L'article fournit une liste de vérification utile pour choisir une pile pour le codage par IA. D'abord, vous devez sélectionner une LLM capable de fonctionner en mode agent et résolvant normalement les tâches de programmation ; pour une évaluation approximative, l'auteur recommande d'examiner l'équilibre entre qualité, prix, vitesse et taille de la fenêtre de contexte. Ensuite — choisir l'agent lui-même : la compatibilité avec le modèle requis importe, un ensemble sensé d'outils intégrés, la prise en charge de MCP et, si nécessaire, la capacité multi-agents.

Et ce n'est qu'après cela qu'il est judicieux de travailler sur les prompts. Parmi les techniques que l'auteur considère comme vraiment viables figurent le role prompting, l'apport explicite de contexte, la planification étape par étape, le step-back prompting et l'utilisation d'exemples de code existant ou de tests. La conclusion principale de l'article est que la productivité du développeur croît non pas de la présence d'« une IA quelconque » dans l'éditeur, mais de l'assemblage précis de tout le circuit : un environnement rapide, un modèle approprié, des outils linguistiques et de la discipline dans la formulation des tâches.

Quand un agent voit le projet non par une recherche aveugle de chaînes mais par LSP et MCP, et quand les bons rôles, profils et contexte lui ont été donnés au préalable, il cesse d'être un assistant bruyant et commence à économiser du temps réel sur le code, la navigation et les vérifications.