Open source обещал свободу менять код. ИИ наконец сделал это реальным

Разработчик и автор популярного блога о LLM Саймон Уиллисон написал короткий, но точный комментарий на Hacker News: свобода читать и модифицировать открытый код всегда была скорее теоретической. На практике даже опытные программисты просто не тратили время на чтение чужой кодовой базы — они полагались на то, что это сделает кто-то другой. LLM-агенты вроде Claude Code и Codex меняют это уравнение. Разберём, как использовать этот подход на практике, если вы хотите наконец разобраться, как устроены инструменты, которыми пользуетесь каждый день.

Почему open source обещал больше, чем давал

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

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

Именно поэтому большинство пользователей open source никогда не пользовались обещанной свободой — они просто ждали, пока кто-то другой из сообщества сделает нужный патч.

Что изменилось с приходом LLM-агентов

Уиллисон описывает свою текущую рутину: несколько раз в день он открывает обычный чат с Claude и пишет что-то вроде «склонируй x/y с GitHub и объясни, как работает Z». Раньше даже сама задача — заставить чужой проект скомпилироваться — была достаточным барьером, чтобы отказаться от идеи покопаться в коде.

Теперь это превратилось в задачу с нулевыми издержками времени. Идея простая: вы поручаете агенту (Codex или Claude Code) склонировать репозиторий и собрать проект, а сами возвращаетесь через десять минут посмотреть, что получилось. Если сборка прошла успешно — вы получаете рабочее окружение для экспериментов практически бесплатно с точки зрения вашего личного времени.

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

Как повторить этот воркфлоу у себя

Процесс делится на два уровня — «понять код» и «собрать и хакать код». Для первого достаточно обычного чата с LLM, для второго нужен агент с доступом к терминалу.

Шаг 1. Разберитесь, как работает нужная функция. Откройте чат с Claude (или другой моделью с доступом к веб-поиску и выполнению кода) и сформулируйте запрос максимально конкретно:

`` Склонируй репозиторий organization/repo с GitHub. Найди, где реализована функция X (например, обработка dark mode в настройках). Объясни логику простыми словами и покажи ключевые файлы. ``

Модель сама найдёт репозиторий, просмотрит структуру проекта и вытащит релевантные фрагменты кода. Вы получаете объяснение за минуты вместо часов чтения документации и issues.

Шаг 2. Поручите агенту собрать проект. Здесь нужен инструмент с доступом к shell — Claude Code или Codex CLI. Задача формулируется как отдельное поручение, а не диалог в реальном времени:

``bash git clone https://github.com/organization/repo.git cd repo ``

Дальше вы просто говорите агенту: «Склонируй и собери этот проект, разберись с зависимостями, если сборка падает — почини». И уходите заниматься другими делами. Через 10-15 минут возвращаетесь и смотрите результат — либо рабочее окружение готово, либо агент оставил лог с тем, на чём застрял.

Шаг 3. Пробуйте вносить изменения. Когда сборка прошла, можно просить агента внести конкретную правку: изменить поведение кнопки, убрать телеметрию, добавить недостающую опцию в конфиг. Это уже полноценная попытка воспользоваться той самой свободой, ради которой существует open source.

Где это ломается

Метод работает не всегда одинаково гладко, и об этом стоит помнить, прежде чем полагаться на него в критичных задачах.

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

Объяснение кода без сборки — самый безопасный вариант использования: модель читает исходники и рассказывает логику, не пытаясь ничего запустить. Здесь риск ошибки ниже, но всё равно стоит перепроверять критичные утверждения по самому коду, а не только по пересказу агента.

Доверие к сгенерированным правкам — если агент модифицировал код инструмента, которым вы реально пользуетесь (особенно devtools с доступом к системе или сети), стоит просмотреть diff перед тем, как ставить изменения в постоянное использование. Автоматическая сборка не означает автоматическую безопасность.

Что попробовать дальше

Возьмите инструмент, которым пользуетесь ежедневно и в котором вас что-то раздражает — расширение браузера, CLI-утилиту, небольшой веб-сервис. Найдите его репозиторий на GitHub и попросите Claude или Codex объяснить, как устроена мешающая вам часть функциональности. Если объяснение имеет смысл — переходите ко второму шагу и поручите агенту собрать проект локально.

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

Источники

• Simon Willison: Devtools must be open source (exe.dev)