Основатель GitHub получил 17 миллионов долларов от a16z и создал Git в эпоху Агентов

Написано: Лео

Ты когда-нибудь задумывался, что программирование может полностью измениться? Разработчики переходят от простого использования AI-инструментов к тому, чтобы рассматривать AI как новую базу для построения программного обеспечения. Это не мелкая настройка, а кардинальный сдвиг парадигмы. Представь себе: те основные концепции, к которым мы привыкли — контроль версий, ветвление, код-ревью, даже определение “сотрудничества” — все переосмысливаются под влиянием рабочих процессов, управляемых AI-агентами. Более того, меня поразило, что Git, которым мы пользуемся каждый день, — это инструмент, созданный для работы с патчами в почтовых списках 20-летней давности, а сейчас он должен обслуживать сценарии, где одновременно работают люди-разработчики и группа AI-агентов.

Именно поэтому сообщение о том, что GitButler недавно привлек 17 миллионов долларов на раунде серии A под руководством a16z, заставило меня остановиться и всерьез задуматься. В раунде также участвовали Fly Ventures и A Capital. Интересно, что CEO GitButler, Скотт Чакон, — один из соучредителей GitHub, он написал ту книгу, которую почти каждый разработчик читал — «Pro Git». Почему человек, добившийся огромных успехов в области контроля версий, возвращается к стартапу и переосмысливает, казалось бы, уже решенную проблему? В объявлении он прямо говорит: “Мы не создаем ‘лучший Git’, мы создаем инфраструктуру следующего поколения для построения программного обеспечения.” За этой фразой скрыта глубокая инсайдерская перспектива на будущее разработки.

20-летняя застрявшая ситуация Git: инструмент, созданный для почтовых списков

Многие не знают истории Git. Изначально Git был создан командой Linux-ядра в 2005 году, его философия глубоко укоренилась в традициях Unix. В интервью Скотт упомянул интересную деталь: команда Git никогда не ставила целью сделать дружелюбный интерфейс. Они следовали философии Unix, создав набор низкоуровневых “конвейерных команд”, каждая из которых делает одну простую вещь, а затем их можно соединять через Perl-скрипты для выполнения любых задач. Такой дизайн был очень логичным для того времени, предполагая, что его будут использовать только технические эксперты — например, команда Linux-ядра.

Дальше все известно. Разработчик по имени Паскви написал Perl-скрипты, которые обернули Git в единый пользовательский интерфейс — так появился CLI-командный интерфейс, который мы сейчас знаем. Эти скрипты становились все популярнее и в итоге были слиты в ядро Git, образовав так называемый “фарфоровый слой” (porcelain). Интересно, что эти команды с 2005–2006 годов практически не менялись. Изначально они были написаны на Perl, затем переписаны на C, но логика и интерфейс остались почти без изменений. В книге «Pro Git», написанной в 2009 году, описанные команды до сих пор работают так же.

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

А что сейчас? У нас есть CI/CD, распределенные команды в реальном времени, инструменты код-ревью, автоматизированные тесты и пайплайны деплоя. И самое главное — AI-агенты пишут код в масштабах. Скотт отметил важный момент: мы учим группу AI-агентов использовать инструмент, созданный для патчей в почтовых списках. Это ощущение диссонанса — как будто Тесла едет по дороге, предназначенной для повозки.

Философия Unix в Git создала еще одну проблему: она пытается обслуживать одновременно и машины, и людей. Например, команда “git branch” по умолчанию выводит список веток без интерфейса. Это сделано для того, чтобы вывод был читаемым человеком и одновременно парсился программами. Такой компромисс приводит к тому, что Git не очень дружелюбен для человека и не оптимизирован для машин. Есть опция “–porcelain” для машинного вывода, но она не является стандартной, и многие команды ее не поддерживают.

Новые вызовы эпохи AI-агентов: одного рабочего каталога уже недостаточно

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

Решение — использование worktree, то есть создание нескольких копий репозитория для параллельных задач. Но это создает новые проблемы. Если у вас пять агентов, вам нужны пять полных копий. Хотя Git оптимизировал хранение, это все равно ведет к большому количеству файлов и расходу диска. Более того, эти агенты полностью изолированы друг от друга и не видят, что делают другие, пока не завершат работу и не попытаются слить изменения. Тогда конфликтов уже очень много, и их решение — дорогостоящее.

GitButler предлагает решение — параллельные ветки (parallel branches). Это идея, которая меня поразила. Параллельные ветки — как обычные, но одновременно открытые несколько. Можно получить преимущества worktree (логическая изоляция), не копируя все файлы. Все агенты работают в одном каталоге, но их изменения распределены по виртуальным веткам. В интервью Скотт описал сцену: два агента одновременно редактируют один файл, но их изменения несовместимы. Что происходит? Один агент автоматически накладывает свою ветку поверх другой и продолжает работу, делая коммиты в свою “сложенную” ветку. Такой умный механизм разрешения конфликтов практически невозможен в традиционном Git-рабочем процессе.

Мне особенно понравился эксперимент команды GitButler: они хотели сделать канал чата между несколькими агентами, чтобы те могли общаться и знать, что делают другие. Скотт сказал, что эта идея выглядит очень круто, и они очень хотели ее реализовать. Но после тестирования выяснили, что это не помогает. Агент сам обнаруживает, что кто-то еще редактирует файл, делает выводы и корректирует свою работу. Им не нужно явно общаться, потому что коммуникация сама по себе — накладно и замедляет процесс. Этот опыт очень поучителен: мы не можем просто переносить человеческие модели сотрудничества на AI-агентов, у них свои способы работы.

Переработка интерфейса: для человека, для агента, для скриптов

GitButler недавно выпустил CLI-инструмент, который произвел на меня большое впечатление. Это не просто обертка над Git, а кардинально новый подход к проектированию командной строки. Скотт отметил интересный факт: около 80% разработчиков все еще используют командную строку для работы с Git, несмотря на наличие графических интерфейсов. Причина проста — большинство GUI — это просто обертки над командами, и они не добавляют функциональности, а только замедляют работу. Если ты знаешь, какую команду запустить, проще сделать это напрямую.

Но CLI GitButler — другое. Он предлагает разные форматы вывода для разных сценариев. Если запустить команду без параметров, он даст оптимизированный, читаемый человеком вывод с подсказками и советами. Если добавить “–json”, он выдаст структурированные JSON-данные для автоматической обработки. Они даже рассматривают добавление “–markdown” — специально для AI-агентов, потому что markdown легче внедрять в контекст агента.

Интересно, что они наблюдали за поведением агентов и на основе этого оптимизировали дизайн. Например, хотя есть “–json”, агенты предпочитают использовать человекочитаемый вывод и сами парсят его через jq или Python. Еще один важный момент — после любой команды изменения агенты почти всегда запускают “git status”. Поэтому команда добавила опцию “–status-after”, которая после выполнения показывает статус. Такой подход в классическом Unix не делается, он не очень подходит для скриптов, но для AI-агентов — идеально.

Они также экспериментируют с добавлением подсказок в вывод, например, “если хочешь сделать X, запусти команду Y”. Это не для человека — слишком многословно, — а для агента, чтобы он быстрее принимал решения. Скотт говорит, что это очень интересная UX-задача: нужно воспринимать агента как нового “пользователя”, у которого свои потребности и поведение, отличное от человека.

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

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

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

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

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

Это также меняет будущее код-ревью. Скотт задал острый вопрос: если спросить у большинства разработчиков, читают ли они полностью PR? Анализируют ли каждую строку? Тестируют ли локально? Или просто быстро просматривают и одобряют? Большинство ответит — второе. Не потому, что они безответственные, а потому что полноценное ревью — дорого и не всегда оправдано.

AI-агенты могут кардинально изменить правила игры. Они отлично умеют детально проверять каждую строку, запускать тесты, искать потенциальные проблемы. Они не устают, не утомляются и могут придерживаться одних и тех же стандартов. Тогда человек сможет сосредоточиться на более высоком уровне: соответствует ли изменение продуктовой стратегии? решает ли оно реальные задачи пользователей? архитектурные решения. А детали — грамматика, потенциальные баги — пусть проверяет AI.

PR и Issue: эволюция давно застоявшихся методов совместной работы

Механизм Pull Request на GitHub стал стандартом для open-source, но Скотт считает, что он содержит фундаментальные недостатки. PR основан на ветках, а не на патчах. Это приводит к тому, что много “мусорных” коммитов — типа “починил баг”, “забыл добавить файл” — некачественные сообщения, которые не помогают понять суть. В PR важна вся ветка, а не отдельные коммиты. Поэтому часто описание PR — единственный источник информации, а оно исчезает после слияния.

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

Еще одна важная тема — коммуникация внутри команд. В разработке часто плохо налажена реальная коммуникация. Если ты редактируешь файл, а я — тоже, мы обычно узнаем о конфликте только при слиянии. Тогда один из нас вынужден делать всю работу по объединению. А что если мы могли бы знать, что делает другой, в реальном времени? Для человека это сложно — накладно и мешает работе. Для AI-агентов — нет. Они могут использовать свободное время для общения, узнавать, кто что делает, предвидеть конфликты и избегать их.

GitButler исследует систему метаданных, которая могла бы хранить диалоги, размышления агентов и контекст. Сейчас Git плохо поддерживает такие данные. Но они могут быть очень ценными для понимания причин решений и мыслей за кодом. Правда, это создает проблему масштабируемости: даже просто хранение текста быстро растет. Они используют технологии из больших репозиториев, например, Chrome или Microsoft Office, чтобы управлять объемами данных.

Мои мысли о предстоящих переменах

После знакомства с GitButler и интервью с Скоттом у меня остались глубокие впечатления. Разработка программного обеспечения переживает фундаментальный сдвиг, и системы контроля версий, как инфраструктура, должны эволюционировать. Идея Git, которая была передовой 20 лет назад, сейчас стала ограничением. Нам нужен не просто “лучший Git”, а новая инфраструктура, адаптированная к современным рабочим процессам и эпохе AI.

Особенно мне близки слова Скотта о “логической точке завершения”. Он говорит, что в области языкового обучения многие считают, что технологии мгновенного перевода убьют языковое обучение. Но он возражает: даже с идеальным переводчиком, оба участника все равно будут носить переводчики, и коммуникация не будет такой же, как при общем языке. Он сам работал неделю с переводчиком в Японии — опыт был хороший, но неидеальный. И он считает, что для построения глубоких связей или сложных проектов лучше говорить на одном языке. То же самое и в программировании. Даже самые мощные AI-агенты не смогут полностью заменить человеческое суждение, креативность и коммуникацию.

Что касается будущего GitHub, я согласен с мнением Скотта. Главный плюс GitHub — его огромная аудитория, а минус — сложность быстрого изменения. Сейчас все ищут “следующий GitHub”, но Скотт говорит, что это неправильный вопрос. GitHub — это не просто платформа, а новая модель сотрудничества. В будущем может появиться совершенно иной, пока еще невидимый формат совместной работы.

Я считаю, что ценность GitButler — не только в конкретных функциях, а в образе мышления, который он представляет. Они ставят под сомнение привычные предположения: почему можно работать только в одной ветке? Почему коммиты должны быть линейными? Почему агенты и люди используют одинаковый интерфейс? Почему сотрудничество должно строиться через PR и Issue? Такой подход, исходящий из первых принципов, — именно то, что нам нужно в быстро меняющемся мире.

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

17 миллионов долларов инвестиций в GitButler — только начало. Я уверен, что в ближайшие годы мы увидим еще больше инициатив по переосмыслению инфраструктуры разработки. Контроль версий, код-ревью, управление проектами, тестирование, деплой — все эти инструменты были созданы в эпоху до AI и требуют обновления. Те команды и разработчики, которые первыми адаптируются к новым парадигмам, получат значительное преимущество.

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