# Open source обещал свободу менять код. ИИ наконец сделал это реальным
Каноническая страница: https://plainews.ru/posts/ai-open-source-devtools-hack
Опубликовано: 2026-08-04T07:01:11.516Z

Саймон Уиллисон показал: Claude Code и Codex убрали главный барьер 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)