Засновник GitHub раніше отримав 17 мільйонів доларів від a16z і створив Git у епоху агентів

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

Чи задумувалися ви, що програмування може кардинально змінитися? Розробники переходять від простого використання AI-інструментів до сприйняття AI як нової основи для створення програмного забезпечення. Це не дрібна зміна, а повна парадигмальна революція. Уявіть собі, що ті ключові концепції, які ми завжди вважали очевидними — контроль версій, гілки, код-рев’ю, навіть визначення “співпраці” — тепер переосмислюються через призму AI-агентів і нових робочих процесів. Більше того, Git, який ми використовуємо щодня, насправді був створений для роботи з патчами у поштових списках понад 20 років тому, і тепер він має служити сценаріям одночасної роботи людських розробників і групи AI-агентів.

Саме тому новина про те, що GitButler щойно отримав 17 мільйонів доларів інвестицій у раунді А, змусила мене зупинитися і серйозно задуматися. Цей раунд очолили a16z, а Fly Ventures і A Capital продовжили інвестувати. Ще цікавіше, що CEO GitButler, Скотт Чакон, — один із співзасновників GitHub і автор майже кожного розробника відомої книги «Pro Git». Людина, яка вже досягла значних успіхів у сфері контролю версій, чому вона повертається до стартапу і переосмислює цю, здавалося б, вже “вирішену” проблему? У своїй заяві він прямо сказав: “Ми не створюємо ‘кращий Git’, ми створюємо інфраструктуру наступного покоління для побудови програмного забезпечення.” За цими словами прихована глибока інсайдерська перспектива щодо майбутнього розробки.

20 років застою 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-агентів використовувати інструменти, створені для поштових патчів. Це — дисонанс, наче Tesla їде дорогою, призначеною для коней.

Філософія Unix у дизайні Git створила ще одну проблему: вона намагається обслуговувати і комп’ютер, і людину одночасно. Наприклад, команда “git branch” за замовчуванням видає список гілок без будь-якого інтерфейсу користувача. Це зроблено для того, щоб вихід був і для читання людиною, і для парсингу програмою. Така компромісна архітектура призвела до того, що Git — не дуже дружній для користувача і не оптимізований для машин. Хоча є опція “–porcelain”, яка дає машинно-зчитуваний формат, вона не є стандартною і багато команд її не підтримують.

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

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

Рішення — використання worktree, тобто створення кількох копій репозиторію для кожної задачі. Але це створює нові проблеми: потрібно багато дискового простору і файлів. Крім того, ці агенти ізольовані один від одного і не бачать, що робить інший, доки не завершать і не зіллють зміни. А тоді — конфлікти, які важко вирішувати.

GitButler пропонує концепцію паралельних гілок (parallel branches). Це — цікава ідея: гілки, що відкриваються одночасно і працюють у спільному каталозі, але кожна у своєму віртуальному просторі. Вони зберігають переваги worktree — ізоляцію логіки — без необхідності дублювати файли. Всі агенти працюють у одному каталозі, але їхні зміни розподілені по віртуальних гілках. У інтерв’ю Скотт описав ситуацію: два агенти одночасно редагують один файл, але їхні зміни несумісні. Що робить GitButler? Один агент автоматично накладає свою гілку на іншу, створюючи стек змін і продовжуючи роботу. Це — розумне і автоматичне вирішення конфліктів, яке раніше було неможливим у класичних Git-робочих процесах.

Я особливо ціную експеримент GitButler, коли вони намагалися зробити між агентами чат для обговорення роботи. Це — дуже крута ідея, але після тестування вони зрозуміли, що це не додає цінності. Агент самостійно виявляє, що інший агент працює з файлом, і автоматично коригує свою поведінку. Вони не потребують явної комунікації — вона створює накладні витрати і сповільнює процес. Це — важливий висновок: ми не можемо просто копіювати людські моделі співпраці на агентів, вони мають свої особливості.

Перезапуск інтерфейсу: для людей, агентів і скриптів

Останній реліз CLI GitButler мене дуже зацікавив. Це — не просто обгортка Git, а новий підхід до дизайну командного рядка. Скотт зазначив, що близько 80% розробників досі користуються командним рядком, навіть якщо існують графічні інтерфейси. Причина — графічні інструменти зазвичай просто обгортають стандартні Git-команди і не додають функціональності, а іноді й гальмують роботу. Якщо знаєш, яку команду потрібно — швидше набрати її, ніж кликати по GUI.

GitButler пропонує інший підхід. Він адаптує вихідні дані під різні сценарії: для користувача — зручний, з підказками і рекомендаціями; для скриптів — структурований JSON; для агентів — формат Markdown, що легко інтегрується у контекст. Вони навіть розглядають додавання “–markdown” для агентів, щоб формат був ще зручнішим.

Ще цікавіше, що вони спостерігають за поведінкою агентів і оптимізують інтерфейс відповідно. Наприклад, хоча є “–json”, агенти частіше використовують людський формат і потім обробляють його через jq або Python. Вони додали опцію “–status-after”, щоб автоматично показувати статус після будь-якої зміни — це суперечить класичним UNIX-інстинктам, але ідеально підходить для агентів.

Вони також досліджують, як додати у вихідні дані підказки: “Якщо хочеш зробити це — виконай цей команду”. Це — не для людини, а для агента, щоб пришвидшити його рішення. Це — новий тип UX, де агент — це новий “користувач”, і його потреби відрізняються від людських.

Глибокі зміни у розробці: від написання коду до формулювання специфікацій

У інтерв’ю Скотт підняв ідею, що у майбутньому найкращі розробники — це не ті, хто пише найкращий код, а ті, хто найкраще комунікує і описує свої ідеї. Це здається несподіваним, адже багато хто обрав програмування саме через можливість спілкуватися з машиною, а не з людьми. Але ця тенденція цілком логічна.

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

Ця нова модель дозволяє робити “покази і обговорення” (show and tell). Замість довгих технічних документів — швидкий прототип, який можна показати команді і отримати зворотний зв’язок. Це прискорює цикл від ідеї до валідації.

Але це створює нові виклики: тепер головне — досягти консенсусу щодо цілей, а не просто реалізувати функцію. Багато розробників вважають, що їхній код — найкращий документ, і не потребують додаткових пояснень. У епоху AI це вже не працює. Потрібно чітко формулювати свої наміри і створювати специфікації, зрозумілі і команді, і AI. Навички письма стають новою суперсилою.

Майбутнє код-рев’ю: від формальності до ефективності

Скотт підняв питання: чи справді більшість інженерів читають кожен ряд коду під час рев’ю? Чи тестують локально? Більшість просто швидко переглядають і схвалюють. Це — не через недбалість, а через високу вартість і низький профіт глибокого аналізу.

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

PR і Issue: еволюція колективної роботи

Механізм Pull Request на GitHub став стандартом, але Скотт вважає, що він має суттєві недоліки. PR базується на гілках, а не на патчах, тому багато “сміттєвих” комітів — наприклад, “виправив помилку” або “забув додати файл” — не мають значення. Важливий — опис PR, але він не зберігається у історії Git і часто зникає після злиття.

У поштових списках кожен патч містив докладний опис, і рев’ю базувалося на самому патчі. Це — більш прозорий і контрольований процес. У сучасних інструментах цей зв’язок втрачається. Скотт пропонує повернутися до рев’ю на основі патчів, але з використанням сучасних можливостей: локальне тестування, автоматичне запускання тестів агентами, фокус на важливих змінах.

Ще одна ідея — покращити комунікацію між командами. Якщо б агенти могли обмінюватися інформацією у реальному часі, вони б могли попереджати один одного про конфлікти ще до злиття. Це — не проблема для AI, бо вони можуть використовувати “метадані” — записи про обговорення, думки, контекст. Але це створює великі обсяги даних, і потрібно ефективно їх зберігати і обробляти.

Мої роздуми щодо цієї революції

Після ознайомлення з історією GitButler і думками Скотта я відчуваю, що розробка програмного забезпечення переживає глибоку зміну парадигми. Інфраструктура, яка ще 20 років тому була передовою, тепер стримує прогрес. Нам потрібна не просто “краща версія Git”, а нова основа, адаптована до сучасних реалій і AI-епохи.

Особливо мені близька ідея про “логічну точку” — що у майбутньому найкращі розробники будуть ті, хто найкраще вміє формулювати ідеї, описувати вимоги і спілкуватися. Це — не відхід від технічних навичок, а їхній доповнювач. Адже коли AI здатен швидко реалізувати ідею, головне — чітко її сформулювати.

Це також змінює уявлення про код-рев’ю. Замість довгих і важких процесів — швидкий і точний аналіз за допомогою агентів, що дозволить зекономити час і зосередитися на стратегічних питаннях.

Революція у колективній роботі — це не лише нові інструменти, а й новий спосіб мислення. Відповідь на питання “чому” і “як” має базуватися на першопринципах, а не на усталених шаблонах. Це — шлях до більш гнучкої, швидкої і ефективної розробки.

Висновок

Розвиток GitButler і ідеї Скотта — це лише початок. У найближчі роки ми побачимо багато нових підходів до інфраструктури, що дозволять адаптуватися до епохи AI. Контроль версій, рев’ю, управління проектами — все це потребує переосмислення. Ті, хто зможуть швидко адаптуватися і впровадити нові концепції, отримають значну перевагу.

Загалом, майбутнє програмування — це більше про комунікацію, співпрацю і прийняття рішень, ніж про синтаксис і технічні деталі. Це — позитивна зміна, яка зробить розробку більш людською, креативною і орієнтованою на цінність. І GitButler — один із перших кроків у цьому напрямку.