Go Developer Survey 2025: ИИ-инструменты повседневны, но качество кода хромает | AiManual
AiManual Logo Ai / Manual.
22 Янв 2026 Новости

Опрос Go-разработчиков 2025: ИИ-тулзы стали как зубная щетка, а качество кода — как кариес

Результаты опроса 5379 Go-разработчиков. ИИ-инструменты стали рутиной, но качество генерации кода и его интеграция в реальные проекты оставляют желать лучшего.

ИИ в Go-разработке: все используют, но всем недовольны

Если год назад использование нейросети для написания кода было темой для хвастовства на митапах, то сегодня это примерно так же интересно, как рассказывать про использование мыши. Опрос Go Developer Survey 2025 года, в котором поучаствовали 5379 человек, рисует картину полной и бесповоротной рутинизации ИИ-инструментов. Но за этой рутиной скрывается знакомый всем разработчикам раздрай: инструмент есть, а толку от него — в лучшем случае половина.

Средний балл "практической полезности" ИИ-ассистентов — 6.8 из 10. Зато балл за "техническую применимость сгенерированного кода" падает до 3.9. Проще говоря, ИИ научился болтать о коде, но писать его так, чтобы это можно было сразу запушить в продакшен — нет. И это при том, что самые свежие модели вроде GPT-4.5 (релиз от октября 2025) или Claude 3.7 Sonnet (декабрь 2025) уже умеют "понимать" контекст проекта лучше своих предшественников.

Контекст: похожая история наблюдается и в других нишах. Например, в нашем опросе 1С-разработчиков Cursor AI также неожиданно стал лидером, что говорит о тренде на глубокую интеграцию ИИ в конкретные IDE, а не просто в чат-интерфейсы.

Что реально используют: GitHub Copilot, Cursor и локальные модели

Распределение предпочтений предсказуемо, но с нюансами.

Инструмент% использующих регулярноОсновная претензия (цитата из опроса)
GitHub Copilot58%"Предлагает устаревшие паттерны, не знает про generics в Go 1.23."
Cursor AI34%"Отлично для прототипов, но код требует полной переработки под продакшен."
Локальные модели (Ollama, LM Studio)22%"Скорость ниже, но зато конфиденциальность и нет лимитов."
ChatGPT / GPT-4.565%"Для общих вопросов и документации — ок. Для кода — часто галлюцинирует."
Claude (3.5/3.7)28%"Лучше справляется с анализом больших кусков кода, но слишком многословен."

Интересный тренд — рост популярности локальных моделей в 2.5 раза за последний год. Разработчики устали от лимитов токенов и вопросов безопасности. Запустить модельку типа DeepSeek-Coder-V2 или Qwen2.5-Coder на своей машине стало проще простого. Правда, плата за это — производительность и актуальность знаний. Модель, обученная в середине 2024, может не знать про новые фичи Go 1.23, вышедшей в августе 2025.

💡
Используете локальные модели? Не забудьте регулярно обновлять их или искать варианты с возможностью дообучения на актуальной документации. Статичная модель быстро устаревает в быстро меняющейся экосистеме Go.

Где ИИ реально экономит время, а где — создает проблемы

Ответы разбили все задачи на три категории: "Зеленую", "Желтую" и "Красную".

Зеленая зона (работает отлично):

  • Написание boilerplate-кода: Генерация структур, интерфейсов, заглушек для HTTP-обработчиков. С этим справляется даже старый Copilot.
  • Создание тестов: Написание unit-тестов для простых функций — одна из самых сильных сторон современных кодогенерирующих моделей.
  • Документирование: Генерация комментариев godoc по уже написанному коду. Здесь ИИ почти идеален.

Желтая зона (работает с оговорками):

  • Рефакторинг: Модель может предложить разбить большую функцию, но часто предлагает странные способы это сделать, нарушая связи в кодовой базе.
  • Поиск багов: Находит очевидные nil pointer dereference или ошибки в циклах, но пропускает сложные race condition или проблемы с конкурентностью, которые для Go критичны.
  • Объяснение чужого кода: Полезно для быстрого погружения, но часто объяснения поверхностны и не затрагивают бизнес-логику.

Красная зона (лучше не трогать):

  • Проектирование архитектуры: Предложения по структуре пакетов или взаимодействию модулей часто абстрактны и не учитывают специфику проекта.
  • Работа с унаследованным кодом (legacy): ИИ теряется в лабиринте старых паттернов и может предложить "оптимизации", которые все сломают.
  • Написание сложной бизнес-логики: Самое слабое место. Модель не понимает контекста доменной области и генерирует логически некорректный код.

Главный вывод: ИИ — отличный стажер-энтузиаст, который быстро накидает черновик. Но отправлять его черновик в продакшен без тщательного ревью старшего разработчика — путь к техническому долгу и ночным дежурствам. Это подтверждает и наше исследование "как ИИ на работе не экономит время, а раскрывает потенциал".

Проблема №1: ИИ не знает вашу кодовую базу (даже если говорит, что знает)

Самая частая жалоба — это непонимание контекста. Cursor AI или Copilot с их обещаниями "видеть весь проект" на деле часто ограничиваются парой открытых файлов. Если у вас монорепозиторий на 100+ микросервисов, ИИ-ассистент в панике.

"Я прошу написать клиент для нашего внутреннего gRPC-сервиса, а он генерирует код для стандартного REST API, потому что это чаще встречалось в его тренировочных данных", — пишет один из респондентов. Это фундаментальная проблема: модели обучаются на открытых репозиториях, а не на ваших приватных конвенциях и доменных моделях.

Экосистема Go с её акцентом на простоту и стандартизацию здесь одновременно и помогает, и мешает. Помогает, потому что ИИ хорошо выучил стандартную библиотеку и популярные пакеты вроде Gin или Cobra. Мешает, потому что когда все пишут "правильно и одинаково", модель не может предложить что-то действительно уникальное или оптимальное для вашего конкретного случая.

Что дальше? Из стажеров — в ассистенты по ревью

Тренд, наметившийся в конце 2025 года, — смещение фокуса с генерации кода на его анализ. Инструменты начинают встраиваться в CI/CD пайплайны не для того, чтобы писать код, а для того, чтобы его проверять.

Представьте: пулл-реквест создан человеком, а ИИ-агент, обученный на ваших прошлых ревью и гайдлайнах, автоматически проверяет его на соответствие стандартам, ищет потенциальные утечки памяти (актуально для Go!) или антипаттерны конкурентности. Такой сценарий кажется гораздо более реалистичным, чем полная замена разработчика. Фактически, мы наблюдаем "конец эры джунов" и превращение мидлов в "менеджеров моделей".

Качество ИИ-кода будет расти не столько из-за улучшения моделей (хотя и это важно), сколько из-за лучшей интеграции. Когда ваш ИИ-ассистент будет иметь безопасный доступ не к паре файлов, а ко всей истории изменений, тикетам в Jira и даже записям стендапов — тогда он сможет генерировать что-то действительно полезное. Пока же это умный, но слепой помощник.

Совет напоследок: не ждите от ИИ чудес. Используйте его как супер-автодополнение и генератор идей. Но ключевые архитектурные решения и сложную логику оставьте себе. И обязательно настройте линтеры и статические анализаторы построже — чтобы отлавливать "галлюцинации" нейросети до того, как они попадут в мастер. В конце концов, ответственность за код в репозитории несете вы, а не какой-то там GPT.