Flant: How a Go Developer Turned Zed and Gemini into a Useful AI Agent

Go-разработчик из «Фланта» описал практический путь, который знаком многим командам: от любопытства к ИИ-плагинам и разочарования в них — к рабочей схеме, где агент действительно снимает с разработчика часть рутины. Главная мысль статьи проста: сама по себе LLM почти не повышает продуктивность, если у неё плохой доступ к контексту проекта, медленный интерфейс и неподходящие инструменты для конкретного языка. Сначала автор прошёл через типичный сценарий раннего внедрения.

В GoLand 2022 он попробовал AI-плагин со встроенной облачной моделью и получил от него три режима: автодополнение, чат и агент. Автоподсказки немного ускоряли работу, но часто ошибались из-за ограниченного контекста. Чат внутри IDE быстро превратился в бесконечную синхронизацию состояния проекта: модель делала допущения, а разработчик тратил время на пояснения.

Агентский режим умел писать и рефакторить код, но слишком часто требовал ручной переделки, так что цикл «поставить задачу — проверить — переписать» оказывался дольше, чем обычная работа без ИИ. Следующий этап был уже с корпоративным доступом к нескольким моделям. Качество ответов у GPT-4o автор оценил заметно выше, чем у GigaChat, но это не решило главную проблему.

Когда компания открыла доступ по API-ключу, в IDE попробовали популярные плагины вроде Cline и Continue. Результат снова оказался слабым: связка IDE, веб-интерфейсной логики и внешней модели тормозила, а работа оставалась тяжёлой. Поворотным моментом стали терминальные агенты.

OpenCode был популярен у коллег, но автор выбрал Crush из-за более удобной установки и того, что инструмент написан на Go. Именно там он впервые получил реальную пользу: агент мог анализировать проект, читать файлы, писать код и использовать LSP и MCP. Однако и терминальный агент не стал финальной точкой.

Для повседневной работы с Git-репозиторием и кодовой базой всё ещё не хватало удобства редактора. Поэтому автор перешёл на Zed — быстрый редактор на Rust со встроенной AI-панелью, собственным агентом и поддержкой внешних агентов через ACP. В статье он подробно разбирает, как подключить Zed к корпоративному LLM-сервису через Open-WebUI и OpenAI-совместимый API, выбрать модель Gemini 3 Flash и настроить профиль write с нужными инструментами: diagnostics, read_file, grep, list_directory, terminal, thinking и web_search.

Отдельно подчёркивается практичная деталь: API-ключ не хранится в файле настроек и вводится вручную через интерфейс редактора. Самая важная техническая часть касается языка Go и качества контекста. Автор показывает на простом примере, что встроенный grep находит только текстовые совпадения и легко уводит модель в неверные предположения, если запрос сформулирован расплывчато.

Чтобы агент работал ближе к семантике кода, он подключает gopls в экспериментальном режиме MCP. Поскольку обычный LSP в Zed пока ориентирован на человека, а не на агента, приходится поднимать отдельный gopls-mcp с собственными переменными окружения и увеличенным таймаутом. Зато после этого агент получает инструменты другого класса: обзор workspace, API пакетов, поиск символов, ссылки на символы, безопасное переименование, диагностику и даже проверку зависимостей на известные уязвимости.

Из статьи получается полезная памятка по выбору стека для AI coding. Сначала нужно подобрать LLM, которая умеет работать в агентском режиме и нормально решает задачи программирования; для грубой оценки автор советует смотреть на баланс качества, цены, скорости и размера контекстного окна. Затем — выбирать самого агента: важны совместимость с нужной моделью, вменяемый набор встроенных tools, поддержка MCP и, при необходимости, мультиагентность.

И только после этого имеет смысл заниматься промптами. Среди техник, которые автор считает реально рабочими, — role prompting, явное прикладывание контекста, пошаговое планирование, step-back prompting и использование примеров из существующего кода или тестов. Главный вывод статьи в том, что разработческая продуктивность растёт не от присутствия «какого-нибудь ИИ» в редакторе, а от точной сборки всего контура: быстрой среды, подходящей модели, языковых инструментов и дисциплины в постановке задач.

Когда агент видит проект не через слепой поиск по строкам, а через LSP и MCP, и когда ему заранее заданы правильные роли, профили и контекст, он перестаёт быть шумным ассистентом и начинает экономить реальное время на коде, навигации и проверках.