Summary & Insights
If you ask almost any software developer, when you do code review, do you really read the whole PR? The answer often reveals a painful truth: we skim, we assume, and we skip testing. This casual approach to reviewing code isn’t just a human flaw—it exposes a deeper problem. Git, the backbone of modern software development, was never designed with collaboration or modern workflows in mind. It started as Unix plumbing commands for the Linux kernel team, with no intention of being user-friendly. As Scott Chacon, GitHub co-founder and GitButler CEO, explains: “The most widely used developer tool in the world was never designed.” For two decades, Git’s interface has barely changed, built on assumptions that no longer hold for humans—or increasingly, for the AI agents now writing code.
The rise of coding agents has turned Git’s quirks into critical bottlenecks. Agents struggle with basic Git commands like rebasing, run `status` after every operation, and misinterpret outputs because the tool was built for command-line scripting, not machine interaction. GitButler addresses this by creating persona-specific interfaces: a CLI optimized for agents (with JSON or markdown outputs tailored to their needs), a TUI for humans, and a GUI for visual workflows. Crucially, it handles parallel branches natively—allowing multiple agents to work on the same codebase without conflicts—something plain Git can’t do. This isn’t just about convenience; it’s about solving inter-team communication, a problem software development has never adequately addressed. As Chacon puts it, “it’s actually a thing that has never been good in software development is inter-team communication.”
The deeper shift isn’t technical—it’s cognitive. With AI handling implementation details, the new superpower isn’t writing code but communicating it clearly. Developers who can write specs, describe requirements, and document workflows will outperform those who only focus on logic. “The software developers that will be the best producers of product in the near future are the ones who can communicate, the ones who can write, the ones who can describe,” Chacon says. Metadata is becoming as critical as code itself: transcripts, prompts, and agent conversations need to be tracked and organized. But this creates a new challenge—how to manage the massive, unstructured data generated by AI workflows without drowning in noise. The future isn’t about more code, but better communication and context.
Surprising Insights
- Agents actually prefer human-readable output over JSON—even though JSON is “machine-friendly”—because they waste time parsing it into usable formats. GitButler now optimizes for this by providing contextual hints or markdown-specific outputs.
- Parallel branches (not work trees) let multiple agents work on the same codebase without conflicts, as they can see each other’s changes in real-time and automatically stack branches when needed. Plain Git can’t do this at all.
- Metadata management becomes a massive data problem almost instantly; small projects generate enormous volumes of agent logs and transcripts, requiring specialized tools just to keep it searchable and useful.
Practical Takeaways
- For teams using AI agents, prioritize tools that automatically include contextual hints (like pre-loading status outputs) rather than forcing agents to parse raw data. This reduces wasted cycles and improves collaboration efficiency.
- Invest in documenting why you’re building something, not just how. Clear specs and requirements will become your most valuable output as AI handles implementation—focus on describing goals, not technical minutiae.
- Test agent workflows for communication: set up lightweight channels (like shared chat threads) for agents to coordinate changes. They’re better at this than humans, and it prevents redundant work or conflicts before they happen.
Nếu bạn hỏi bất kỳ nhà phát triển phần mềm nào, khi thực hiện code review, bạn có thực sự đọc toàn bộ PR không? Câu trả lời thường tiết lộ một sự thật đau lòng: chúng ta đọc lướt, đưa ra giả định và bỏ qua kiểm thử. Cách tiếp cận qua loa này không chỉ là lỗi của con người—nó phơi bày một vấn đề sâu xa hơn. Git, nền tảng của phát triển phần mềm hiện đại, chưa bao giờ được thiết kế để hướng đến hợp tác hoặc quy trình làm việc hiện đại. Nó bắt đầu từ các lệnh Unix plumbing dành cho nhóm Linux kernel, không hề có ý định thân thiện với người dùng. Như Scott Chacon, đồng sáng lập GitHub và CEO GitButler, giải thích: “Công cụ phát triển được sử dụng rộng rãi nhất thế giới chưa bao giờ được thiết kế.” Trong hai thập kỷ, giao diện Git gần như không thay đổi, được xây dựng trên những giả định không còn phù hợp với con người—hay ngày càng với các tác nhân AI đang viết mã.
Sự xuất hiện của các tác nhân mã hóa đã biến các đặc điểm kỳ lạ của Git thành những điểm nghẽn nghiêm trọng. Các tác nhân gặp khó khăn với các lệnh Git cơ bản như rebase, chạy `status` sau mỗi thao tác và hiểu sai đầu ra bởi công cụ được thiết kế cho kịch bản dòng lệnh, không phải tương tác với máy. GitButler giải quyết điều này bằng cách tạo ra các giao diện được thiết kế riêng theo persona: CLI được tối ưu cho tác nhân (đầu ra JSON hoặc Markdown phù hợp với nhu cầu), TUI cho con người, và GUI cho workflow trực quan. Điều quan trọng là, GitButler xử lý nhánh song song bản địa—cho phép nhiều tác nhân làm việc trên cùng mã nguồn mà không xung đột—điều mà Git thông thường không thể làm được. Điều này không chỉ là tiện lợi; mà còn là giải quyết vấn đề giao tiếp giữa các nhóm—một vấn đề phát triển phần mềm chưa bao giờ giải quyết đầy đủ. Như Chacon nói: “Thực ra, giao tiếp giữa các nhóm là điều mà phát triển phần mềm chưa bao giờ làm tốt.”
Sự thay đổi sâu xa không phải về mặt kỹ thuật—mà là nhận thức. Khi AI xử lý chi tiết triển khai, sức mạnh mới không phải là viết code mà là truyền đạt rõ ràng. Những nhà phát triển có thể viết tài liệu, mô tả yêu cầu và tài liệu hóa workflow sẽ vượt trội hơn những người chỉ tập trung vào logic. “Những nhà phát triển phần mềm sẽ trở thành những người tạo sản phẩm tốt nhất trong tương lai gần là những người có thể giao tiếp, có thể viết, có thể mô tả,” Chacon nói. Siêu dữ liệu đang ngày càng quan trọng như chính code: các bản ghi, prompt và cuộc trò chuyện của tác nhân cần được theo dõi và sắp xếp. Nhưng điều này tạo ra thách thức mới: làm sao quản lý lượng dữ liệu khổng lồ không cấu trúc phát sinh từ workflow AI mà không bị chìm đắm trong tiếng ồn. Tương lai không phải là code nhiều hơn, mà là giao tiếp và ngữ cảnh tốt hơn.
Những phát hiện bất ngờ
- Các tác nhân thực sự thích đầu ra dễ đọc cho con người hơn JSON—dù JSON được gọi là “thân thiện với máy”—vì chúng tốn thời gian phân tích thành định dạng sử dụng được. GitButler hiện tối ưu bằng cách cung cấp gợi ý ngữ cảnh hoặc đầu ra Markdown đặc thù.
- Nhánh song song (không phải cây làm việc) cho phép nhiều tác nhân làm việc trên cùng mã nguồn mà không xung đột, vì chúng có thể xem thay đổi của nhau theo thời gian thực và tự động chồng nhánh khi cần. Git thông thường hoàn toàn không thể làm được điều này.
- Quản lý siêu dữ liệu trở thành vấn đề dữ liệu lớn ngay tức thì; các dự án nhỏ tạo ra lượng lớn nhật ký và bản ghi của tác nhân, đòi hỏi công cụ chuyên dụng chỉ để giữ chúng có thể tìm kiếm và hữu ích.
Bài học thực tế
- Với các nhóm dùng tác nhân AI, hãy ưu tiên công cụ tự động thêm gợi ý ngữ cảnh (như tải sẵn đầu ra status) thay vì buộc tác nhân phân tích dữ liệu thô. Điều này giảm chu trình lãng phí và cải thiện hiệu quả hợp tác.
- Đầu tư vào việc ghi chú lý do bạn xây dựng thứ gì đó, chứ không chỉ là phương pháp. Các đặc tả và yêu cầu rõ ràng sẽ trở thành đầu ra có giá trị nhất khi AI xử lý triển khai—hãy tập trung mô tả mục tiêu, không phải chi tiết kỹ thuật nhỏ lẻ.
- Thử nghiệm workflow giao tiếp của tác nhân: thiết lập kênh nhẹ (như luồng chat chung) để tác nhân phối hợp thay đổi. Chúng làm việc này tốt hơn con người và ngăn chặn công việc trùng lặp hoặc xung đột trước khi xảy ra.
如果詢問幾乎任何一名軟體開發者，在進行代碼審查時是否真的會閱讀整個 PR，答案往往揭示了一個痛點：我們只是略讀、想當然，還跳過測試。這種輕率的代碼審查方式不僅是人類的缺點，更暴露了更深層的問題。Git 作為現代軟體開發的骨幹，從未考慮過協作或現代工作流程而設計。它最初是為 Linux 核心團隊開發的 Unix 管道命令，根本沒有打算做得用戶友好。GitHub 聯合創辦人兼 GitButler CEO 斯科特·夏昆解釋道：「世界上最廣泛使用的開發者工具從未被設計過。」二十多年來，Git 的介面幾乎沒有變化，其背後的假設已不再適用於人類，甚至對日益增多、正在編寫代碼的 AI 代理也是如此。
編碼代理的興起讓 Git 的怪癖變成關鍵瓶頸。代理在處理基礎 Git 命令（如變基、每次操作後運行`status`、誤解輸出）時困難重重，因為該工具是為命令列腳本設計，而非機器互動。GitButler 透過建立針對不同角色的介面來解決此問題：針對代理優化的命令列介面（使用 JSON 或 Markdown 輸出以符合其需求）、人類使用的文字使用者介面（TUI），以及用於視覺化工作流程的圖形使用者介面（GUI）。關鍵在於，它原生支援平行分支——允許多個代理在同一代碼庫上無衝突運作——這點 Git 本身完全無法做到。這不僅是便利問題，更是解決團隊間溝通的問題，而這恰是軟體開發從未妥善處理的難題。正如夏昆所言：「團隊間溝通是軟體開發中從未真正做好的環節。」
更深層的轉變非技術性，而是認知層面。當 AI 處理實現細節，新的超能力不再是寫代碼，而是清晰地溝通。能寫出規格說明、描述需求和記錄工作流程的開發者將超越僅專注邏輯的人。「未來最具生產力的軟體開發者，是那些具備溝通、撰寫和描述能力的人，」夏昆說。元資料變得與代碼本身同等重要：對話紀錄、提示詞和代理對話都需要被追蹤與整理。但這也帶來新挑戰——如何管理 AI 工作流程產生的大量非結構化數據，而不被信息噪音淹沒。未來不在於增加更多代碼，而在於更優質的溝通與上下文。
驚人洞見
- 代理其實更偏好人類可讀的輸出，而非 JSON——儘管 JSON 被稱為「對機器友好」——因為它們在解析成可用格式時浪費大量時間。GitButler 現在優化此點，透過提供情境提示或 Markdown 專用輸出來應對。
- 平行分支（非工作樹）允許多個代理在同一代碼庫上無衝突協作，因為它們能實時查看彼此變更，並在需要時自動疊加分支。Git 本身完全無法做到這點。
- 元資料管理幾乎立刻變成龐大數據問題；小型專案即會產生大量代理日誌和對話紀錄，僅為了維持可搜索與實用性就需要專用工具。
實際應用建議
- 對於使用 AI 代理的團隊，應優先選擇能自動加入情境提示（例如預載狀態輸出）的工具，而非強迫代理解析原始數據。這能減少資源浪費，提升協作效率。
- 重點記錄「為什麼」要開發某功能，而不僅是「如何」。當 AI 處理實現細節後，清晰的規格與需求將成為最具價值的產出——關注描述目標，而非技術細節。
- 測試代理溝通流程：建立輕量級溝通渠道（如共享聊天串），讓代理協調變更。它們在這方面優於人類，能在冗餘工作或衝突發生前預防。
Si le preguntas a casi cualquier desarrollador de software: durante la revisión de código, ¿lees realmente toda la PR? La respuesta a menudo revela una verdad dolorosa: leemos de pasada, asumimos y omitimos realizar pruebas. Este enfoque despreocupado para revisar código no es solo un fallo humano — revela un problema más profundo. Git, la columna vertebral del desarrollo de software moderno, nunca fue diseñado con la colaboración o flujos de trabajo modernos en mente. Comenzó como comandos plumbing de Unix para el equipo del kernel de Linux, sin intención de ser amigable para los usuarios. Como explica Scott Chacon, cofundador de GitHub y CEO de GitButler: “La herramienta de desarrollo más utilizada en el mundo nunca fue diseñada”. Durante dos décadas, la interfaz de Git apenas ha cambiado, basada en suposiciones que ya no valen para los humanos — o cada vez más, para los agentes de IA que ahora escriben código.
El auge de los agentes de codificación ha convertido las rarezas de Git en cuellos de botella críticos. Los agentes tienen dificultades con comandos básicos de Git como el rebasing, ejecutan `status` después de cada operación y malinterpretan las salidas porque la herramienta fue creada para scripting de línea de comandos, no para interacción con máquinas. GitButler aborda esto creando interfaces específicas para cada persona: una CLI optimizada para agentes (con salidas en JSON o markdown adaptadas a sus necesidades), una TUI para humanos y una GUI para flujos de trabajo visuales. Crucialmente, maneja ramas paralelas de forma nativa — permitiendo que múltiples agentes trabajen en la misma base de código sin conflictos — algo que Git puro no puede hacer. Esto no se trata solo de comodidad; se trata de resolver la comunicación entre equipos, un problema que el desarrollo de software nunca ha abordado adecuadamente. Como dice Chacon: “Lo que nunca ha sido bueno en el desarrollo de software es la comunicación entre equipos”.
El cambio más profundo no es técnico — es cognitivo. Con la IA manejando detalles de implementación, la nueva superpotencia no es escribir código sino comunicarlo claramente. Los desarrolladores que pueden escribir especificaciones, describir requisitos y documentar flujos de trabajo superarán a quienes solo se enfocan en la lógica. “Los desarrolladores de software que serán los mejores productores de productos en el futuro cercano son los que pueden comunicarse, los que pueden escribir, los que pueden describir”, dice Chacon. Los metadatos se están volviendo tan críticos como el propio código: transcripciones, prompts y conversaciones de agentes necesitan ser rastreados y organizados. Pero esto crea un nuevo desafío: cómo manejar los masivos datos no estructurados generados por flujos de trabajo de IA sin ahogarse en ruido. El futuro no se trata de más código, sino de una mejor comunicación y contexto.
Insights sorprendentes
- Los agentes prefieren salidas legibles por humanos sobre JSON —a pesar de que JSON es “amigable para máquinas”— porque pierden tiempo parseándolo a formatos utilizables. GitButler ahora optimiza esto proporcionando pistas contextuales o salidas específicas para markdown.
- Las ramas paralelas (no los árboles de trabajo) permiten que múltiples agentes trabajen en la misma base de código sin conflictos, ya que pueden ver los cambios de los demás en tiempo real y apilar ramas automáticamente cuando sea necesario. Git puro no puede hacer esto en absoluto.
- El manejo de metadatos se convierte casi instantáneamente en un problema de datos masivo; proyectos pequeños generan volúmenes enormes de registros y transcripciones de agentes, requiriendo herramientas especializadas solo para mantenerlos buscables y útiles.
Consejos prácticos
- Para equipos que usan agentes de IA, prioriza herramientas que incluyan automáticamente pistas contextuales (como pre-cargar salidas de estado) en lugar de obligar a los agentes a parsear datos crudos. Esto reduce ciclos desperdiciados y mejora la eficiencia de la colaboración.
- Invierte en documentar por qué estás construyendo algo, no solo cómo. Las especificaciones claras y los requisitos se convertirán en tu salida más valiosa mientras la IA maneja la implementación: enfócate en describir objetivos, no en minucias técnicas.
- Prueba los flujos de trabajo de los agentes para comunicación: configura canales livianos (como hilos de chat compartidos) para que los agentes coordinen cambios. Son mejores en esto que los humanos, y previenen trabajo redundante o conflictos antes de que sucedan.
Se você perguntar a quase qualquer desenvolvedor de software se, durante uma revisão de código, lê realmente todo o PR, a resposta frequentemente revela uma verdade dolorosa: passamos os olhos, assumimos e pulamos testes. Essa abordagem relaxada à revisão de código não é apenas um erro humano – expõe um problema mais profundo. Git, a espinha dorsal do desenvolvimento de software moderno, nunca foi projetado pensando em colaboração ou fluxos de trabalho modernos. Começou como comandos de tubulação do Unix para a equipe do kernel do Linux, sem intenção de ser amigável ao usuário. Como Scott Chacon, co-fundador do GitHub e CEO do GitButler, explica: “A ferramenta de desenvolvimento mais amplamente utilizada no mundo nunca foi projetada.” Por duas décadas, a interface do Git praticamente não mudou, construída sobre suposições que já não se aplicam a humanos – ou, cada vez mais, a agentes de IA que agora escrevem código.
O surgimento de agentes de codificação transformou as peculiaridades do Git em gargalos críticos. Agentes têm dificuldade com comandos básicos do Git como rebase, executam `status` após cada operação e interpretam mal as saídas porque a ferramenta foi criada para scripts de linha de comando, não para interação com máquinas. GitButler resolve isso criando interfaces específicas por persona: uma CLI otimizada para agentes (com saídas em JSON ou markdown adaptadas às suas necessidades), uma TUI para humanos e uma GUI para fluxos de trabalho visuais. De forma crucial, ele lida nativamente com branches paralelos – permitindo que diversos agentes trabalhem no mesmo código sem conflitos – algo que o Git padrão não consegue fazer. Isso não se trata apenas de conveniência; é resolver a comunicação entre equipes, um problema que o desenvolvimento de software nunca resolveu adequadamente. Como Chacon disse: “O que nunca foi bom no desenvolvimento de software é a comunicação entre equipes.”
A mudança mais profunda não é técnica – é cognitiva. Com a IA lidando com detalhes de implementação, o novo superpoder não é escrever código, mas comunicá-lo claramente. Desenvolvedores que conseguem escrever especificações, descrever requisitos e documentar fluxos de trabalho superarão aqueles que se concentram apenas em lógica. “Os desenvolvedores de software que serão os melhores produtores de produtos no futuro próximo são aqueles que podem se comunicar, aqueles que podem escrever, aqueles que podem descrever”, diz Chacon. Metadados estão se tornando tão críticos quanto o próprio código: transcrições, prompts e conversas de agentes precisam ser rastreados e organizados. Mas isso cria um novo desafio: como gerenciar os enormes volumes de dados não estruturados gerados por fluxos de trabalho de IA sem se afogar no ruído. O futuro não se trata de mais código, mas de melhor comunicação e contexto.
Insights surpreendentes
- Agentes preferem saídas legíveis por humanos em vez de JSON – mesmo que JSON seja “amigável para máquinas” – porque perdem tempo processando-o em formatos utilizáveis. GitButler agora otimiza isso fornecendo dicas contextuais ou saídas específicas para markdown.
- Branches paralelos (não árvores de trabalho) permitem que múltiplos agentes trabalhem no mesmo código sem conflitos, já que conseguem visualizar as alterações uns dos outros em tempo real e empilham branches automaticamente quando necessário. O Git padrão não consegue fazer isso de jeito nenhum.
- A gestão de metadados se torna um problema de dados enorme quase instantaneamente; projetos pequenos geram volumes imensos de logs e transcrições de agentes, exigindo ferramentas especializadas apenas para mantê-los pesquisáveis e úteis.
Dicas práticas
- Para equipes que usam agentes de IA, priorize ferramentas que incluem automaticamente dicas contextuais (como pré-carregar saídas de status) em vez de obrigar agentes a analisar dados brutos. Isso reduz ciclos desperdiçados e melhora a eficiência da colaboração.
- Invista em documentar por que você está construindo algo, não apenas como. Especificações claras e requisitos serão seu resultado mais valioso à medida que a IA lidar com a implementação – foque em descrever metas, não em detalhes técnicos minuciosos.
- Teste fluxos de trabalho de agentes para comunicação: configure canais leves (como threads de chat compartilhadas) para que os agentes coordenem alterações. Eles são melhores nisso que humanos e evitam trabalho redundante ou conflitos antes que aconteçam.
Matt Bornstein speaks with Scott Chacon, cofounder of GitHub and CEO of GitButler, about why Git’s user interface has barely changed since 2005, how GitButler is rethinking version control for both humans and AI agents, and what the “next GitHub” might actually look like. They cover parallel branches, agent-optimized CLI design, the future of code review, and why the best engineers of the future will be the best writers.
Resources:
Follow Scott Chacon on X: https://twitter.com/chacon
Follow Matt Bornstein on X: https://twitter.com/BornsteinMatt
Stay Updated:
Find a16z on YouTube: YouTube
Find a16z on X
Find a16z on LinkedIn
Listen to the a16z Show on Spotify
Listen to the a16z Show on Apple Podcasts
Follow our host: https://twitter.com/eriktorenberg
Please note that the content here is for informational purposes only; should NOT be taken as legal, business, tax, or investment advice or be used to evaluate any investment or security; and is not directed at any investors or potential investors in any a16z fund. a16z and its affiliates may maintain investments in the companies discussed. For more details please see a16z.com/disclosures.
Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.
