Gas Town: когда ИИ‑агенты — это твой новый продакшн-завод
Привет, %username% ! Мне тут попалась статья Steve Yegge "Welcome to Gas Town" (она на Medium — может быть сложно открыть), где он вещает не столько про конкретный тул, сколько про новый уровень работы с ИИ‑разработкой: не "подсказал модельке функцию", а построил целый завод, где роятся специализированные агенты и сами двигают фичи от идеи до merge.
Что вообще такое Gas Town
- Это оркестратор "стаи" AI‑кодеров (Claude Code и аналоги), где каждый агент играет свою роль: координатор, исполнители, отдельные роли для слияния и шлифовки изменений.
- По сути, это "Kubernetes для агентов": не один большой ассистент, а куча мелких, которые параллельно пишут, чинят, рефакторят и мержат код.
Ключевая идея архитектуры
- Главный инсайт — не тащить всё обратно к "боссу"-агенту, а дать агентам самим работать с общей git‑подобной базой (Beads) и артефактами.
- Это снимает узкое место "суперагента", у которого забивается контекст и который тормозит всю систему. Вместо этого у тебя распределённая "фабрика задач".
Как это ощущается разработчику
- Steve Yegge описывает это как индустриализированный конвейер: "coding factory manned by superintelligent robot chimps" — если неправильно с ними обращаться, они могут быстро "сломать тебе всё".
- Система нестабильная, дорогая и хаотичная: она требует опытного "дрессировщика агентов", а не новичка, который надеется "нажать одну кнопку и получить продукт".
Принципы и ограничения
- Фокус не на аптайме, а на доведении задач до конца: автор называет это "nondeterministic idempotence" — агенты могут падать и перезапускаться, пока итоговый результат стабилизируется.
- Gas Town — это не продукт "для всех", а песочница для тех, кто готов жить в режиме high-touch: много наблюдать, перенастраивать, управлять процессами и рисками.
Важный тезис Такое оркестрирование требует новых практик: observability для агентов, release‑менеджмент их изменений, политики безопасности и контроля доступа для ИИ‑фабрики.
Как тебе сама идея "Kubernetes для агентов"? Хотелось бы запустить у себя стаю ИИ‑разработчиков, которые параллельно чинят, пишут и рефакторят код, или это путь в бесконечный хаос и отладку? Что бы ты стал мониторить в таком “агент‑кластере”: качество диффов, частоту откатов, стоимость токенов, MTTR агентов? Видишь ли ты за этим ближайшее будущее разработки или считаешь, что это скорее игрушка для энтузиастов?
#AI #DevTools #SRE #DevOps #agents #ClaudeCode #Orchestration
· 23.01
Газтаун – отличная метафора, чтобы сразу расставить все точки над ы: агенты не помощники, а производственный конвейер. Они или в разы ускоряют работу, или превращают репозиторий в помойку.
Главное здесь не в параллельной разработке, а в смещении узкого места. Раньше тормозили люди и время, а теперь – контроль качества и управление изменениями.
где многие споткнутся: начнут считать токены и скорость, вместо того чтобы оценивать цену ошибок. Один быстрый агент, который уверенно льет мусор, обойдется дороже медленного человека.
Если честно, то Kubernetes для агентов без правил – это не Kubernetes, а просто толпа джунов.
Поэтому в агент-кластере я бы следил в первую очередь за:
Качеством изменений Частотой откатов Change Failure Rate (доля релизов, ломающих систему) MTTR (время восстановления системы)
И только потом – за стоимостью токенов.
агенты – это не про скорость написания кода, а про создание конвейера с предсказуемой, повторяемой и контролируемой работой.
По сути, это уже не разработка, а операционка: очереди, роли, ограничения, качество, наблюдаемость и безопасность.
Будущее? Да. Игрушка для гиков? Только без отлаженного процесса. Если все настроить как систему, это станет стандартом очень быстро.
ответить
коммент удалён