На дворе 2026 год, и любые рассуждения о разработке с AI-агентами рискуют устареть быстрее, чем мы допишем README.md в нашем репозитории. Тем не менее некоторые вещи уже начинают выглядеть не как временный шум, а как новые инженерные практики.

Одна из таких вещей — изменение отношения к языкам программирования.

Раньше мы часто выбирали язык программирования по тому, насколько на нём удобно писать человеку. Насколько он выразителен или позволяет быстро накидать прототип. Насколько приятно читать написанный код через полгода, когда ты уже забыл, зачем вообще всё это делал.

AI меняет картину. Если заметную часть кода пишет не человек, а агент, то удобство языка остаётся важным для нас, разработчиков, но перестаёт быть единственным критерием при выборе языка программирования для нового проекта. Внезапно оказывается, что язык должен быть удобен ещё и для агентного цикла: сгенерировал код, собрал проект, прогнал тесты, получил ошибку, исправил, повторил.

И в таком цикле Go выглядит неожиданно хорошо.

Так ли критичны недостатки Go

Go всегда был немного странным языком в глазах людей, привыкших к более выразительным альтернативам. Он простой, иногда слишком. Многословный и без особой магии, с ручной обработкой ошибок. С кодом, который часто выглядит так, будто его писал очень дисциплинированный, но слегка потерявший интерес к программированию разработчик.

Примерно так:

data, err := os.ReadFile(path)
if err != nil {
    return fmt.Errorf("read config %q: %w", path, err)
}

Никакой поэзии — зато всё понятно.

Такая многословность иногда раздражает. Писать однотипную обработку ошибок руками — удовольствие так себе. Генерировать обвязку, тесты, HTTP-ручки, конфигурацию, простые клиенты к API — тоже не самая вдохновляющая работа.

Но AI-агентам для написания кода всё равно. Они не страдают от кучи похожего кода, не закатывают глаза на очередной if err != nil. Они просто генерируют код, а потом получают от компилятора и тестов обратную связь.

В этот момент недостатки Go перестают быть такими уж серьёзными. А старые достоинства — простота, явность, единообразие — становятся гораздо важнее.

AI любит предсказуемость

Чем больше в языке и экосистеме вариантов сделать одно и то же, тем выше шанс, что модель выберет не тот вариант.

В экосистемах вроде JavaScript или Python это видно особенно хорошо. Исторически там накопилось много способов собрать проект, управлять зависимостями, писать асинхронный код, строить веб-приложения, описывать конфигурацию и раскладывать файлы по директориям.

Для опытного разработчика это пространство выбора. Для модели — пространство для галлюцинаций.

Go устроен иначе. В нём меньше вариантов, меньше магии, меньше стилистической свободы. Типичный Go-код часто похож на другой Go-код, и это не баг, а фича. У языка есть стандартный форматтер, понятный набор инструментов, быстрый компилятор, простая модель сборки и достаточно единообразная культура написания кода. Это делает Go удобным не только для людей, но и для AI-агентов.

Модель лучше работает там, где меньше случайности. Go как раз про это.

Хороший агентный цикл важнее синтаксиса

В разработке c AI-ассистентами и агентами не надо верить, что модель сразу напишет идеальный код — это завышенное ожидание. Скорее всего, не напишет. Или напишет почти правильно, что иногда даже хуже.

Нормальный процесс выглядит иначе: план → генерация кода → сборка → тесты → исправления → ревью.

И чем проще этот цикл, тем лучше:

gofmt -w .
go test ./...
go vet ./...
golangci-lint run

Ошибки компилятора обычно конкретные. Тесты запускаются просто. Форматирование единое. Линтеры можно встроить в CI. Сборка проекта не требует сложного окружения и скриптов. Во многих случаях на выходе получается один бинарник, который легко положить в контейнер и отправить в продакшен.

Такие скучные вещи делают AI-разработку безопаснее. Промптами можно объяснить агенту многое, но не всё. А вот компилятор, тесты, линтеры, контракты API и CI-проверки не интерпретируют задачу творчески, как это могут делать модели. Они просто говорят: вот здесь сломано, чини.

Такие инструменты гораздо надёжнее, чем надеяться на длинный промпт в духе «пожалуйста, пиши хороший код».

Go как язык для разработки с кодинговыми агентами

AI не отменяет инженерную дисциплину. Скорее наоборот: он делает её важнее.

Когда в проекте появляются агенты, цена плохих тестов, слабого CI, неясных контрактов и хаотичной структуры кода растёт. Агент может быстро написать много кода. Но если среда не умеет этот код проверять, мы просто быстрее получим больше проблем и технического долга.

В этом смысле Go интересен не сам по себе, а как пример правильной экосистемы для новой реальности:

• меньше магии, больше явности
• быстрый feedback loop
• хорошие инструменты из коробки
• простая сборка под любую архитектуру и ОС

Не самый красивый язык, не самый выразительный и не самый модный. Но очень удобный для мира, где код всё чаще пишется в паре с машиной.

И, возможно, именно поэтому Go сейчас выглядит сильнее, чем несколько лет назад. Не потому что он изменился, а потому что изменился контекст вокруг него.