Соберём это: как превратить coding agents из личных инструментов в командную инфраструктуру

Давай начистоту: если в твоей команде разработчики используют coding agents, скорее всего, ты уже плаваешь в хаосе.

У каждого свои MCP-настройки, кастомные промпты, автоматизационные скрипты, доступные только этому человеку, и ноль видимости в то, что происходило, когда agent выполнял задачу. Твоя «командная инфраструктура» — это на самом деле набор персональных костылей, скреплённых надеждой и устными знаниями.

Именно с этой проблемой столкнулась компания Assembled. Их coding agents отлично работали для отдельных инженеров — но вот surrounding workflow был… скажем так, неухоженным.

Проблема персональных coding agents

Типичная картина: разработчик А настроил Claude Code на свой GitHub fork и Linear. Разработчик Б предпочитает Codex с интеграцией в Sentry и своими уведомлениями в Slack. Разработчик В собрал такую машину Голдберга из скриптов, что в ней разбирается только он.

А теперь вопросы:

• Что происходит, когда кто-то уходит из команды?
• Как воспроизвести, что именно agent сделал?
• Как проверить, совпадает ли output agent'а с тем, что реально оказалось в коммите?

И всё — ты в тупике.

Корневая проблема не в том, полезны ли coding agents (они полезны). Проблема в том, что мы используем их как личные текстовые редакторы вместо того, чтобы выстроить из них командную инфраструктуру. И это порождает три серьёзных вопроса:

1. Silo знаний — только один человек знает, как настроен agent
2. Пробелы в воспроизводимости — нельзя легко повторить или проверить действия agent'а
3. Барьеры для коллаборации — то, что работает у одного инженера, не помогает команде

143.dev: coding agents как shared infrastructure

Assembled решила эту задачу internally и решила открыть решение для сообщества. Так появился 143.dev — платформа, которая превращает coding agents в инфраструктуру с общим доступом.

Идея элегантная: вместо того чтобы запускать agents локально на машинах разработчиков, ты разворачиваешь их в стандартизированных окружениях с единым tooling и полной видимостью.

Вот как это выглядит на практике:

Несколько agents, единая платформа. Система запускает Codex, Claude Code, OpenCode и другие agent harnesses в gVisor-песочницах. Это значит, что можно миксовать и матчить в зависимости от стоимости, возможностей и типа задачи. Команда Assembled, например, использует GLM 5.2 для рутинных задач автоматизации (дешевле, быстрее), а Codex или Claude Code — для более сложной ручной работы. Одна инфраструктура, разные agents для разных задач.

Интеграции из коробки. Система подключается к GitHub, Linear, Sentry, Slack, PagerDuty и другим. Preview'и генерируются без проблем. Agent'ы не работают в изоляции — они встроены в твой существующий workflow.

Безопасность без трения. gVisor-песочницы обеспечивают изоляцию без головной боли от управления полноценными VM. Agent'ы могут делать своё дело, но в рамках containment.

MIT-лицензия и возможность self-hosting. Это не hosted SaaS, которому ты должен доверить свой код. Можно посмотреть исходники, развернуть на своей инфраструктуре и адаптировать под свои нужды. Assembled вдохновлялась Stripe Minions и системой Ramp Inspect, но хотела создать что-то, что сможет использовать и модифицировать всё сообщество.

Почему это важно для стартапов и растущих команд

Вот что стоит понимать про coding agents: они будут только набирать популярность. И по мере роста команды подход «персональные скрипты» перестаёт работать.

Тебе нужны:

• Audit trails — что именно agent изменил?
• Reproducibility — можешь ли ты запустить ту же задачу повторно?
• Обмен знаниями — может ли кто угодно в команде использовать agent workflows?
• Безопасность — получает ли agent доступ только к тому, что должен?

143.dev бьёт по этим проблемам напрямую. И то, что это open source, значит, тебе не нужно ставить свою инфраструктуру на карту стартапа, который может не существовать через два года.

Общая картина

Мы входим в фазу, когда AI coding tools — это уже не новинки, а инфраструктура. А инфраструктуру нужно управлять как инфраструктурой: с visibility, reproducibility и командным доступом.

Personal coding agents — это отправная точка. Team-managed agent infrastructure — вот где начинается самое интересное.

Если ты управляешь стартапом или инженерной командой, имеет смысл глянуть на 143.dev. Код на GitHub, MIT-лицензия. Никакого vendor lock-in, никаких скрытых платежей — просто open infrastructure, которую можно адаптировать под то, как работает твоя команда.

Иногда лучшие internal tools — это те, которыми стоит поделиться.