Почему devtools должны быть open source

04.08.2026 · 5 мин

Помните, когда вы в последний раз бились головой о стену, пытаясь настроить закрытый инструмент так, как вам нужно? Я — помню. Помню, как читал документацию три раза, писал на форумах, открывал тикеты. И в итоге просто смирялся с тем, что инструмент делает не совсем то, что мне нужно.

Автор статьи на exe.dev blog поднимает важный вопрос: в мире, где AI-агенты стали нормой, закрытые devtools становятся узким местом. И вот почему.

Проблема: закрытые инструменты ограничивают вас

Пять лет назад большинство инженеров, с которыми общался автор, не писали софт для себя. Все работали в чужом коде, настраивали чужой софт через конфиги и плагины. Кастомизация была головной болью: изучи исходники, напиши плагин, интегрируй — и молись, чтобы после ближайшего обновления ничего не сломалось.

Закрытые инструменты добавляют слой проблем:

Классический пример — Vim. Ядро Vim огромное и запутанное. Добавить простую фичу вроде показа номеров строк по умолчанию? Изучайте код неделями. Проще написать конфиг, который всё равно не покроет все случаи.

ЗАКРЫТЫЙ ИНСТРУМЕНТ
───────────────────
┌─────────────────────────────────────┐
│  Вы  │─────┐                        │
│      │     ▼                        │
│      │  ┌──────────────────┐        │
│      │  │   ЧЕРНЫЙ ЯЩИК    │        │
│      │  │                  │        │
│      │  │  API? Плагины?   │        │
│      │  │  Только то, что  │        │
│      │  │  дали. И не      │        │
│      │  │  факт, что то,   │        │
│      │  │  что нужно.      │        │
│      │  └────────┬─────────┘        │
│                 │                   │
└─────────────────┼───────────────────┘
                  │ Хотите изменить?
                  │ Нельзя.
                  ▼
              [Печаль]
Закрытый инструмент: вы взаимодействуете с интерфейсом, но не контролируете поведение

Решение: открытый код меняет правила игры

Автор описывает, как AI-агенты трансформировали стоимость персонализации. Раньше это было дорого: потрать недели на изучение кодовой базы, сделай изменение, молись при апдейте.

Теперь? Два промпта:

Скачай исходник <софт>, собери локально.
Измени <память агента> так, чтобы будущие изменения 
этого софта = изменение исходников и замена версии.

И второй — для автоматической синхронизации с апстримом:

Каждую ночь: забери изменения из апстрима, 
наложи свои правки, проверь, что работает, замени версию.

Это не фантастика. Автор рассказывает, как они встроили в своего агента Shelley возможность редактировать себя. Хотите интерфейс с высокой контрастностью? Одного запроса достаточно — агент сам найдёт код, изменит его, пересоберёт.

Что это значит на практике

Автор приводит конкретный пример. Он использует meat.dev — инструмент, который прогоняет diff-файлы через LLM и убирает «мясо» из «кости».

Проблема: meat работает в терминале, а автор предпочитает UI в Shelley. Плюс LLM тратит пару минут на обработку — ждать не хочется.

Один промпт:

Встрой meat.dev в Shelley. Установи последнюю версию.
Когда Shelley делает коммит — запускай meat в фоне.
Добавь кнопку в UI для просмотра обработанного diff'а.

Результат: Shelley сам устанавливает tool, сам препроцессит коммиты, сам добавляет UI. Единственное «но» — агент выбрал эмодзи для кнопки. Мелочь, но показательная.

Закройте этот код в бинарник — и вся эта магия невозможна. Плагины VS Code? Vimdiff? Они не знают, что делать с препроцессингом на лету. Пришлось бы писать обходные костыли.

ЭКОСИСТЕМА OPEN SOURCE DEVTOOLS
════════════════════════════════
         ┌─────────────┐
         │    ВЫ       │
         └──────┬──────┘
                │
    ┌───────────┼───────────┐
    │           │           │
    ▼           ▼           ▼
┌────────┐ ┌────────┐ ┌────────┐
│Прозра-│ │Аудит   │ │Вклад   │
│чность │ │безопас-│ │сообщест-│
│       │ │ности   │ │ва      │
└───┬────┘ └───┬────┘ └───┬────┘
    │           │           │
    └───────────┼───────────┘
                │
                ▼
    ┌─────────────────────────┐
    │  ЛУЧШИЕ ИНСТРУМЕНТЫ     │
    │  = прозрачность × вклад │
    └─────────────────────────┘
Open source создаёт virtuous cycle: прозрачность привлекает аудит, аудит — доверие, доверие — вклад

Выгоды open source devtools

Для пользователей:

Вы проверяете код на GitHub и сразу видите, что meat.dev не отправляет ваш код третьим лицам. Это не теория — это факт, который можно проверить за пять минут. А если найдёте баг? Форкните репозиторий, исправьте, отправьте PR. Через день ваше исправление в мейне.

Для экосистемы:

Когда Pi Agent выложили в open source, контрибьюторы за неделю нашли уязвимость, которую авторы пропустили. Закрытый проект узнал бы о ней от хакера на черном рынке. Открытый — от комьюнити на GitHub.

Для продукта:

Вспомните, сколько раз вы просили фичу и получали «в роадмапе». В open source проекте кто-то из комьюнити просто берёт и делает. Не потому что альтруист — потому что ему самому нужно. Это бесплатная R& D.

Автор сравнивает: Pi — open source, можно редактировать напрямую. Codex — open source, можно кастомизировать. Claude Code? Закрытый. Есть API, есть хуки. Если вам нужно что-то вне хуков — извините.

Риски и как с ними быть

Конечно, open source не без рисков. Главный — кто-то может форкнуть ваш инструмент и увести аудиторию. Или выпустить «вашу» версию с малварью.

Но посмотрим честно: это проблема не open source, а доверия. Если ваш инструмент хорош — пользователи останутся с вами. Если плох — они уйдут в любом случае, просто форк даст им эту возможность быстрее.

Другой риск — фрагментация. Много форков означает много несовместимых версий.

Решение простое: strong opinionated defaults, хорошая документация, активное сообщество. Как Linux. Много дистрибутивов, но ядро одно, и все друг с другом более-менее совместимы.

Моя оценка

Статья попала в точку. Я сам регулярно сталкиваюсь с ситуацией, когда закрытый инструмент делает 80% того, что мне нужно. Оставшиеся 20% — это либо известное ограничение, либо feature request, который рассмотрят «в будущем».

AI-агенты действительно меняют экономику персонализации. Не потому что теперь любой может стать разработчиком, а потому что порог входа в изменение кода упал драматически.

Но есть нюанс, с которым я не согласен. Автор подаёт open source как универсальное решение. На практике — не каждый проект может позволить себе поддерживать community. Это работа: мержить PR, отвечать на issue, писать документацию. Не каждый разработчик или команда к этому готовы.

Ещё пример: не каждый вклад полезен. Я видел PR, которые ломали архитектуру ради удобства одного пользователя. Принять — значит похоронить проект. Отклонить — получить драму на Reddit.

Иногда закрытый код — это осознанное решение. Не злой умысел, а прагматика. У вас нет ресурсов на community management. Или код настолько специфичный, что его поймут пять человек в мире — и те в других компаниях.

Тем не менее, тренд очевиден. Devtools — это инфраструктура доверия. Когда вы выбираете инструмент для работы, вы доверяете ему свой код, свои секреты, свою продуктивность. Закрытый инструмент просит доверия, ничего не давая взамен.

Open source не гарантирует качество. Но он даёт возможность проверить, исправить, улучшить. И в 2024 году, когда AI-агенты могут сделать это за вас — это уже не роскошь, а необходимость.

Вывод

Devtools должны быть open source по умолчанию. Это не про идеологию — это про прагматику. Закрытые инструменты ставят вас в зависимость от воли вендора. Открытые — дают свободу и ответственность одновременно.

Хотите, чтобы ваши инструменты работали на вас, а не наоборот? Требуйте исходный код. Или пишите свои.

Ссылки

Дмитрий Полухин — продуктовый дизайнер. Пишу про разработку, AI и дизайн интерфейсов. Обо мне, контакты и профили.

Что почитать дальше