1 Año Usando Google Jules: De la Experimentación al Desarrollo Autónomo por Oleadas Paralelas
El 11 de junio de 2025, a las 02:05 UTC, Jules hizo el primer push en mi cuenta. El pull request se mergeó a las 03:50 UTC de ese día. Jules estaba en beta pública desde el Google I/O del 20 de mayo. El primer cambio con una feature llegó 22 minutos después, en el mismo pull request.
Al 28 de agosto de 2026, con 11,240 commits contados en 81 repositorios, el flujo ya no es un chat: es una fábrica de software asíncrona y determinista que despacha oleadas de hasta 15 micro-tareas paralelas a Google Jules, coordinadas por Hermes y verificadas por la máquina de estados de GitCore.
Esta es la retrospectiva técnica de ese tramo: la evolución de las herramientas, las soluciones para evitar colisiones de contexto, las métricas del cierre y las lecciones aprendidas.
1. El Inicio: Filosofía Minimalista y Primeras Herramientas
Para junio de 2025 yo ya venía experimentando con agentes de código en local. El corte fue ese primer push de Jules, no un IDE. Google Antigravity no existía: salió el 18 de noviembre de 2025, el mismo día que Gemini 3, como IDE con agentes. Las oleadas de esta nota las despacha Jules.
Mi postura técnica sigue siendo minimalista:
Principio de Fricción Mínima: Entre menos herramientas, extensiones y configuraciones intermedias acumules, más productivo eres. Menos tiempo perdido debatiendo qué editor usar y más tiempo enfocado en resolver el problema.
En esa primavera Google Labs tenía dos cosas distintas. Jules es el agente asíncrono: clona el repo en una VM y devuelve un pull request. Estuvo en beta pública del 20 de mayo al 6 de agosto de 2025. Google Stitch genera interfaz, no parches de un repositorio. Salió el mismo 20 de mayo.
Éramos plenamente conscientes de que operábamos como early adopters (“conejillos de indias”) en una tecnología naciente. Pero también era evidente la visión de fondo: Google no estaba intentando crear otro autocompletador de código local, sino apalancar la infraestructura en la nube más grande del planeta para el desarrollo de software.
2. La Solución al Cuello de Botella: GitHub como Bus de Cómputo
Cualquier ingeniero que haya intentado delegar trabajo a 4 o 5 agentes corriendo simultáneamente en una misma máquina local se estrella contra el mismo muro físico: las colisiones de archivos y la sobrescritura de estado. Dos agentes editando el mismo archivo en local destruyen el espacio de trabajo.
En ese tramo la salida no fue un sistema de archivos virtual, sino el pipeline que la industria ya tenía resuelto: GitHub.
┌────────────────────────────────────────────────────────────────────────┐
│ PIPELINE DISTRIBUIDO DE GOOGLE JULES │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ GitHub Issues Google Cloud Compute Pull Requests │
│ ┌──────────────┐ ┌─────────────────────┐ ┌─────────────────┐ │
│ │ Spec atómico │ ────► │ Sandbox Aislado │ ──►│ Diff limpio + │ │
│ │ + Criterios │ │ (Jules Agent Run) │ │ Tests verdes │ │
│ └──────────────┘ └─────────────────────┘ └─────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘Al transformar el flujo en Issue → Tarea de Agente Aislada → Pull Request, cada instancia de Jules se ejecuta en un contenedor efímero e independiente respaldado por los datacenters de Google, eliminando cualquier interferencia entre agentes.
Ese aislamiento es el de este tramo: una rama y un pull request por agente. Gestalt VFS, para que varios agentes editen el mismo archivo, es posterior. El artículo del cierre lo cuenta.
El techo de 15 tareas concurrentes
Ese número no existía el 11 de junio. Llegó el 6 de agosto de 2025, cuando Jules salió de beta. En Google AI Pro el cupo quedó en 15 tareas concurrentes. El plan gratis quedó en 3. Desde entonces las oleadas se arman contra ese techo: un agente cierra un hito acotado, no un subsistema entero.
En esa salida Jules usaba Gemini 2.5 Pro. La ventana de más de 1M de tokens alcanzaba para un crate o un módulo con sus tipos y sus pruebas, si el issue no pretendía ser el sistema completo.
3. Del Caos al Arnés: La Creación de GitCore y Sprints de 30 Minutos
A medida que el volumen de PRs creció, empezaron a surgir anomalías: context drift, inconsistencias en dependencias cruzadas y ramas huérfanas. No podíamos depender de la suerte.
Fue allí cuando desarrollé el arnés de ingeniería alrededor de GitCore, transformando el proceso en un ciclo determinista de verificación formal:
- Matriz de Features (
features.json): Cada proyecto define su avance porcentual y criterios de aceptación verificables. - Limpieza Automatizada de Ramas: Reconciliación continua de ramas remotas tras cada merge.
- Baterías de Pruebas E2E y Compilación Estricta: Ningún PR se aprueba si no pasa el 100% de la suite de tests automatizados.
┌──────────────────────────────────────────────────────────────────┐
│ AI SPRINT LIFECYCLE (OLEADA DE 30 MINUTOS) │
├──────────────────────────────────────────────────────────────────┤
│ 1. Lectura de estado previo en Xavier (Memoria) y features.json │
│ 2. Fragmentación en 3-4 micro-issues por feature (Islas) │
│ 3. Auditoría pre-dispatch (0 colisiones de archivos) │
│ 4. Dispatch paralelo a Jules con label 'jules' (hasta 15 tasks) │
│ 5. Monitoreo asíncrono y resolución de suites de tests │
│ 6. Merge secuencial ordenado: Tipos ➔ Core ➔ API ➔ E2E │
│ 7. Actualización de métricas en features.json y cierre de sprint│
└──────────────────────────────────────────────────────────────────┘La revelación fue inmediata: organizar una oleada de agentes es exactamente igual a planificar un Sprint ágil de dos semanas, con la diferencia de que el ciclo de estimación, desarrollo, testeo y entrega se ejecuta en 30 minutos.
4. Métricas al cierre (28 de agosto de 2026)
Los conteos de commits son un escaneo del workspace a la fecha de esta nota. No son el recuento desde el 11 de junio, y las horas no salen de git log.
| Métrica del Ecosistema | Valor |
|---|---|
| Primer push de Jules | 11 de junio de 2025, 02:05 UTC |
| Cierre de este corte | 28 de agosto de 2026 (443 días desde el primer push) |
| Repositorios en el escaneo | 81 repositorios |
| Commits en esos repositorios | 11,240 commits |
| Commits de oleadas (Jules y otros agentes) | 1,391 commits |
Features en features.json |
1,723 especificaciones |
| Pull requests mergeados | 1,000+ PRs |
| Horas equivalentes de trabajo manual | ~6,250 h, estimación, fuera del escaneo |
| Multiplicador | 6.5x – 8.0x, estimación |
Repositorios públicos con más actividad agéntica
La lista de abajo es solo código público. Los totales de la tabla mezclan ese código con otro trabajo que no está publicado. Ese otro trabajo no lleva nombre, enlace ni conteo.
- Xavier: 1,922 commits totales / 255 commits de Jules (Memoria cognitiva vectorial en Rust).
- OrionHealth: 1,243 commits totales / 61 commits de Jules (Salud offline-first en Flutter).
- WorldExams: 844 commits totales / 85 commits de Jules (Práctica de exámenes, offline-first).
- Gestalt: 635 commits totales / 200 commits de Jules (Orquestador multi-agente en Rust).
El inventario local-first está en Shelf.
5. Patrones Clave: Micro-Fragmentación e Islas de Archivos Disjuntas
Para lograr que 15 agentes concurrentes trabajen sin destruirse mutuamente, el arnés implementa dos reglas inviolables:
A. Micro-Fragmentación
Ningún issue supera las 150 líneas de impacto ni abarca más de dos capas arquitectónicas. Cada feature grande se subdivide en:
[Micro-A]: Contratos de tipos, traits y structs.[Micro-B]: Lógica pura de dominio y algoritmos.[Micro-C]: Adaptadores de entrada/salida (HTTP, IPC, CLI).[Micro-D]: Baterías de pruebas unitarias y mocks.
B. Islas de Archivos Disjuntas (Disjoint File Islands)
Antes de despachar una oleada con el label jules, un script valida que la intersección de archivos asignados a cada issue sea un conjunto vacío:
# Verificación de Islas de Archivos Disjuntas (Pre-Dispatch QA)
islands = {
'#issue-101': ['crates/core/src/types.rs'],
'#issue-102': ['crates/core/src/codec.rs'],
'#issue-103': ['crates/api/src/routes.rs'],
'#issue-104': ['crates/core/tests/e2e_test.rs'],
}
for i1, f1 in islands.items():
for i2, f2 in islands.items():
if i1 < i2 and set(f1) & set(f2):
raise SystemExit(f"❌ COLISIÓN DETECTADA: {i1} y {i2} tocan {set(f1) & set(f2)}")
print("✅ 100% Islas Disjuntas Verificadas.")6. La Triada de Infraestructura: GitCore, Hermes y Xavier
Jules no opera en el vacío. La articulación de todo el ecosistema depende de tres pilares diseñados a medida:
┌──────────────────────────────┐
│ XAVIER (Memoria Viva) │
│ Contexto histórico & Vector │
└──────────────┬───────────────┘
│ Context Feed
▼
┌──────────────────┐ ┌──────────────┐ ┌──────────────────┐
│ HERMES GATEWAY │ ───► │ GITCORE CLI │ ───► │ GOOGLE JULES │
│ Despacho Rápido │ │ State Engine │ │ 15 Parallel PRs │
└──────────────────┘ └──────────────┘ └──────────────────┘- GitCore: El arnés maestro que gobierna el contrato 1 Issue → 1 Rama → 1 PR, actualiza
features.jsony corre los linters pre-merge. - Hermes: El dispatcher que gestiona el ciclo de vida de los agentes y los límites de cuota.
- Xavier: Memoria cognitiva persistente con búsqueda semántica vectorial. Alimenta a los issues con decisiones arquitectónicas tomadas meses atrás.
7. Áreas de Mejora y Siguientes Pasos
Desde el primer push, el 11 de junio de 2025, estas son las 4 áreas donde el flujo se está optimizando:
- Aserción Semántica en CI: Integrar validación de compatibilidad de tipos entre ramas de una misma oleada antes de ejecutar el merge a
main. - Alertas Tempranas de Timeout: Detección predictiva cuando un agente supera 15 minutos en tareas de compilación pesada.
- Ingestión en Tiempo Real a Xavier: Webhooks automáticos que indexen el diff de cada PR aprobado en la memoria vectorial.
- Sandboxing Efímero de Red: Aislamiento de sockets y puertos para suites de pruebas concurrentes.
8. Conclusión: La Nueva Era de la Ingeniería
La gran lección de este primer año es contundente: el verdadero salto de productividad no está en escribir código más rápido con un autocompletado en el teclado, sino en diseñar arneses rigurosos que permitan articular enjambres autónomos en paralelo.
Google Jules, respaldado por la potencia de Gemini y orquestado mediante un arnés determinista como GitCore, nos demostró que un solo ingeniero con la arquitectura correcta puede liderar y entregar proyectos con la cadencia, robustez y calidad de un equipo de ingeniería completo.
Continúa la lectura
Las oleadas de 15 issues paralelos que se mencionan en este post (Wave 1, Wave 2, Wave 3) ya tienen un artículo dedicado: Waves: oleadas como sprints de 30 minutos y Gestalt VFS. Allí explico por qué 30 min × N waves vence al sprint clásico, y presento Gestalt VFS como la PoC que rompe el techo de paralelismo (muchos agentes sobre el mismo archivo, merge en Rust).
في 11 يونيو 2025، الساعة 02:05 UTC، نفّذ Jules أول push على حسابي. دُمج طلب السحب في 03:50 UTC من اليوم نفسه. كان Jules في بيتا عامة منذ Google I/O في 20 مايو. وصل أول تغيير يحمل ميزة بعد 22 دقيقة، في طلب السحب نفسه.
بحلول 28 أغسطس 2026، ومع 11,240 commit معدودة في 81 مستودعاً، لم يعد التدفق محادثة. صار مصنع برمجيات غير متزامن وحتمي يرسل موجات تصل إلى 15 مهمة دقيقة متوازية إلى Google Jules، ينسقها Hermes وتتحقق منها آلة حالات GitCore.
هذه هي المراجعة التقنية لتلك الفترة: كيف تطورت الأدوات، وكيف تُجنَّب تصادم السياق، ومقاييس الإغلاق، وما تعلمته.
1. البداية: موقف حدّ أدنى من الأدوات
بحلول يونيو 2025 كنت أجرّب وكلاء كتابة الكود محلياً. الفاصل كان أول push من Jules، لا بيئة تطوير. Google Antigravity لم يكن موجوداً: صدر في 18 نوفمبر 2025، في اليوم نفسه الذي صدر فيه Gemini 3، كبيئة تطوير بوكلاء. موجات هذه الملاحظة يرسلها Jules.
موقفي التقني ما زال في الحد الأدنى:
مبدأ الاحتكاك الأدنى: كلما قلّ ما تراكمه من أدوات وإضافات وإعدادات وسيطة، زاد إنتاجك. وقت أقل في الجدال عن المحرر، ووقت أكثر على المسألة.
في ذلك الربيع كان لدى Google Labs شيئان مختلفان. Jules هو الوكيل غير المتزامن: يستنسخ المستودع في آلة افتراضية ويعيد طلب سحب. بقي في بيتا عامة من 20 مايو إلى 6 أغسطس 2025. Google Stitch يولّد واجهة، لا رقع مستودع. صدر في 20 مايو نفسه.
كنا نعرف أننا نعمل كـ early adopters («فئران تجارب») على تقنية وليدة. والرهان التحتي كان واضحاً أيضاً: Google لم يكن يصنع إكمالاً محلياً آخر للكود. كان يضع أكبر سحابة على الكوكب تحت تطوير البرمجيات.
2. عنق الزجاجة: GitHub ناقل حساب
أي مهندس جرّب تسليم العمل إلى 4 أو 5 وكلاء يعملون معاً على آلة محلية واحدة يصطدم بالجدار الفيزيائي نفسه: تصادم الملفات ومحو الحالة. وكيلان يعدّلان الملف نفسه محلياً يدمّران مساحة العمل.
في تلك الفترة لم يكن المخرج نظام ملفات افتراضياً. كان خط الأنابيب الذي حلّته الصناعة من قبل: GitHub.
┌────────────────────────────────────────────────────────────────────────┐
│ PIPELINE DISTRIBUIDO DE GOOGLE JULES │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ GitHub Issues Google Cloud Compute Pull Requests │
│ ┌──────────────┐ ┌─────────────────────┐ ┌─────────────────┐ │
│ │ Spec atómico │ ────► │ Sandbox Aislado │ ──►│ Diff limpio + │ │
│ │ + Criterios │ │ (Jules Agent Run) │ │ Tests verdes │ │
│ └──────────────┘ └─────────────────────┘ └─────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘حين يصير التدفق issue → مهمة وكيل معزولة → pull request، تعمل كل نسخة من Jules في حاوية قصيرة العمر خاصة بها داخل مراكز بيانات Google، فلا يتداخل الوكلاء.
هذا العزل هو عزل تلك الفترة: فرع واحد وطلب سحب واحد لكل وكيل. Gestalt VFS، كي يعدّل عدة وكلاء الملف نفسه، جاء لاحقاً. مقال الإغلاق يروي ذلك الجزء.
سقف 15 مهمة متزامنة
هذا الرقم لم يكن موجوداً في 11 يونيو. وصل في 6 أغسطس 2025، حين خرج Jules من البيتا. على Google AI Pro صار الحد 15 مهمة متزامنة. بقيت الخطة المجانية عند 3. منذ ذلك تُبنى الموجات على هذا السقف: الوكيل يغلق معلماً محدوداً، لا نظاماً فرعياً كاملاً.
عند ذلك الإطلاق كان Jules يستخدم Gemini 2.5 Pro. نافذة أكثر من 1M رمز تكفي لـ crate أو وحدة، مع أنواعها واختباراتها، إذا لم تدّعِ الـ issue أنها النظام كله.
3. من الفوضى إلى الحزام: GitCore وسبرنتات 30 دقيقة
مع نمو طلبات السحب ظهرت الشذوذات: context drift، واعتماديات متقاطعة، وفروع يتيمة. لم يكن الاعتماد على الحظ ممكناً.
هناك بنيت حزام الهندسة حول GitCore، وحوّلت العملية إلى دورة حتمية للتحقق الشكلي:
- مصفوفة الميزات (
features.json): كل مشروع يحدد نسبة تقدمه ومعايير قبول يمكن التحقق منها. - تنظيف الفروع آلياً: مصالحة مستمرة للفروع البعيدة بعد كل دمج.
- حزم E2E وبناء صارم: لا يُقبل طلب سحب إن لم يجتز 100% من حزمة الاختبارات الآلية.
┌──────────────────────────────────────────────────────────────────┐
│ AI SPRINT LIFECYCLE (OLEADA DE 30 MINUTOS) │
├──────────────────────────────────────────────────────────────────┤
│ 1. Lectura de estado previo en Xavier (Memoria) y features.json │
│ 2. Fragmentación en 3-4 micro-issues por feature (Islas) │
│ 3. Auditoría pre-dispatch (0 colisiones de archivos) │
│ 4. Dispatch paralelo a Jules con label 'jules' (hasta 15 tasks) │
│ 5. Monitoreo asíncrono y resolución de suites de tests │
│ 6. Merge secuencial ordenado: Tipos ➔ Core ➔ API ➔ E2E │
│ 7. Actualización de métricas en features.json y cierre de sprint│
└──────────────────────────────────────────────────────────────────┘كانت النتيجة فورية: تنظيم موجة من الوكلاء هو بالضبط تخطيط سبرنت رشيق من أسبوعين، والفرق أن دورة التقدير والتطوير والاختبار والتسليم تجري في 30 دقيقة.
4. المقاييس عند الإغلاق (28 أغسطس 2026)
أعداد الـ commit هي مسح لمساحة العمل في تاريخ هذه الملاحظة. ليست إعادة عدّ من 11 يونيو، والساعات لا تأتي من git log.
| مقياس المنظومة | القيمة |
|---|---|
| أول push من Jules | 11 يونيو 2025، 02:05 UTC |
| إغلاق هذا القطع | 28 أغسطس 2026 (443 يوماً منذ أول push) |
| المستودعات في المسح | 81 مستودعاً |
| الـ commits في تلك المستودعات | 11,240 commit |
| commits الموجات (Jules ووكلاء آخرون) | 1,391 commit |
الميزات في features.json |
1,723 مواصفة |
| طلبات السحب المدمجة | 1,000+ PR |
| ساعات مكافئة للعمل اليدوي | ~6,250 ساعة، تقدير، خارج المسح |
| المضاعف | 6.5x – 8.0x، تقدير |
المستودعات العامة ذات النشاط الأعلى للوكلاء
القائمة أدناه كود عام فقط. مجاميع الجدول تخلط ذلك الكود بعمل آخر غير منشور. ذلك العمل الآخر بلا اسم ولا رابط ولا عدّ.
- Xavier: 1,922 commit إجمالاً / 255 commit من Jules (ذاكرة معرفية متجهية بلغة Rust).
- OrionHealth: 1,243 commit إجمالاً / 61 commit من Jules (صحة offline-first بـ Flutter).
- WorldExams: 844 commit إجمالاً / 85 commit من Jules (تدريب على الامتحانات، offline-first).
- Gestalt: 635 commit إجمالاً / 200 commit من Jules (منسق متعدد الوكلاء بلغة Rust).
جرد المخزون المحلي-أولاً على Shelf.
5. أنماط أساسية: التجزئة الدقيقة وجزر الملفات المنفصلة
لكي يعمل 15 وكيلاً متزامناً من غير أن يدمّر بعضهم بعضاً، يفرض الحزام قاعدتين لا تنثنيان:
A. التجزئة الدقيقة
لا تتجاوز أي issue أثر 150 سطراً ولا تغطي أكثر من طبقتين معماريتين. كل ميزة كبيرة تُقسم إلى:
[Micro-A]: عقود الأنواع وtraits وstructs.[Micro-B]: منطق نطاق خالص وخوارزميات.[Micro-C]: محولات دخل/خرج (HTTP وIPC وCLI).[Micro-D]: حزم اختبار وحدة وmocks.
B. جزر ملفات منفصلة
قبل إرسال موجة بوسم jules، يتحقق سكربت من أن تقاطع الملفات المخصصة لكل issue مجموعة فارغة:
# Verificación de Islas de Archivos Disjuntas (Pre-Dispatch QA)
islands = {
'#issue-101': ['crates/core/src/types.rs'],
'#issue-102': ['crates/core/src/codec.rs'],
'#issue-103': ['crates/api/src/routes.rs'],
'#issue-104': ['crates/core/tests/e2e_test.rs'],
}
for i1, f1 in islands.items():
for i2, f2 in islands.items():
if i1 < i2 and set(f1) & set(f2):
raise SystemExit(f"❌ COLISIÓN DETECTADA: {i1} y {i2} tocan {set(f1) & set(f2)}")
print("✅ 100% Islas Disjuntas Verificadas.")6. ثلاثي البنية: GitCore وHermes وXavier
Jules لا يعمل في فراغ. تماسك المنظومة كلها قائم على ثلاثة أعمدة صُنعت لهذا:
┌──────────────────────────────┐
│ XAVIER (Memoria Viva) │
│ Contexto histórico & Vector │
└──────────────┬───────────────┘
│ Context Feed
▼
┌──────────────────┐ ┌──────────────┐ ┌──────────────────┐
│ HERMES GATEWAY │ ───► │ GITCORE CLI │ ───► │ GOOGLE JULES │
│ Despacho Rápido │ │ State Engine │ │ 15 Parallel PRs │
└──────────────────┘ └──────────────┘ └──────────────────┘- GitCore: الحزام الرئيس. يحكم عقد issue واحدة → فرع واحد → PR واحد، ويحدّث
features.json، ويشغّل المدققات قبل الدمج. - Hermes: الموزّع. يدير دورة حياة الوكلاء وحدود الحصة.
- Xavier: ذاكرة معرفية دائمة ببحث دلالي متجهي. يغذي الـ issues بقرارات معمارية اتُخذت قبل أشهر.
7. ما يزال يُشد
منذ أول push، في 11 يونيو 2025، يُشد التدفق في 4 مواضع:
- تأكيد دلالي في CI: التحقق من توافق الأنواع بين فروع الموجة الواحدة قبل الدمج في
main. - تنبيه مبكر للمهلة: التنبؤ بأن وكيلاً يتجاوز 15 دقيقة في ترجمة ثقيلة.
- إدخال فوري إلى Xavier: webhooks تفهرس diff كل PR مقبول في الذاكرة المتجهية.
- صندوق شبكة قصير العمر: عزل المقابس والمنافذ لحزم الاختبار المتزامنة.
8. الخاتمة: عصر جديد للهندسة
درس هذه السنة الأولى حاد: قفزة الإنتاجية ليست في كتابة الكود أسرع بالإكمال التلقائي. هي في تصميم أحزمة صارمة تشغّل أسراباً ذاتية بالتوازي.
Google Jules، مستنداً إلى Gemini ومنسقاً بحزام حتمي مثل GitCore، بيّن أن مهندساً واحداً بالمعمارية الصحيحة يستطيع أن يقود ويسلّم مشاريع بإيقاع فريق هندسة كامل ومتانته وجودته.
تابع القراءة
موجات الـ 15 issue المتوازية المذكورة هنا (Wave 1 وWave 2 وWave 3) لها مقال خاص: Waves: الموجات كسبرنتات من 30 دقيقة وGestalt VFS. أشرح هناك لماذا 30 دقيقة × N موجة تتفوق على السبرنت الكلاسيكي، وأقدّم Gestalt VFS كإثبات مفهوم يكسر سقف التوازي (وكلاء كثر على الملف نفسه، والدمج بلغة Rust).
১১ জুন ২০২৫, 02:05 UTC-এ Jules আমার অ্যাকাউন্টে প্রথম push করে। সেই দিনই 03:50 UTC-এ pull request মার্জ হয়। Jules ২০ মে-র Google I/O থেকে পাবলিক বেটায় ছিল। ফিচার-সহ প্রথম পরিবর্তন ২২ মিনিট পরে আসে, সেই একই pull request-এ।
২৮ আগস্ট ২০২৬ নাগাদ, ৮১টি রিপোজিটরিতে গোনা 11,240টি commit নিয়ে, প্রবাহ আর চ্যাট নয়। এটি একটি অ্যাসিঙ্ক্রোনাস, নিশ্চিত সফটওয়্যার কারখানা, যা Google Jules-এ সর্বোচ্চ ১৫টি সমান্তরাল ক্ষুদ্র কাজের তরঙ্গ পাঠায়। সমন্বয় করে Hermes, যাচাই করে GitCore-এর স্টেট মেশিন।
এই সময়টার কারিগরি পুনর্বিবেচনা: সরঞ্জাম কীভাবে বদলেছে, প্রসঙ্গের সংঘর্ষ কীভাবে এড়ানো হয়েছে, বন্ধের পরিমাপ, এবং কী শেখা গেছে।
1. শুরু: ন্যূনতম অবস্থান এবং প্রথম সরঞ্জাম
জুন ২০২৫ নাগাদ আমি স্থানীয় কোডিং এজেন্ট নিয়ে কাজ করছিলাম। ছেদটা ছিল Jules-এর সেই প্রথম push, কোনো IDE নয়। Google Antigravity তখন ছিল না: এটি বেরোয় ১৮ নভেম্বর ২০২৫, Gemini 3-এর একই দিনে, এজেন্ট-সহ IDE হিসেবে। এই নোটের তরঙ্গ পাঠায় Jules।
কারিগরি অবস্থান এখনও ন্যূনতম:
ন্যূনতম ঘর্ষণের নীতি: যত কম সরঞ্জাম, এক্সটেনশন এবং মাঝের কনফিগ জমা করবে, তত বেশি উৎপাদনশীল হবে। কোন এডিটর, সেই তর্কে কম সময়, সমস্যায় বেশি সময়।
সেই বসন্তে Google Labs-এর কাছে দুটি আলাদা জিনিস ছিল। Jules অ্যাসিঙ্ক্রোনাস এজেন্ট: একটি VM-এ রিপো ক্লোন করে pull request ফেরত দেয়। পাবলিক বেটা ছিল ২০ মে থেকে ৬ আগস্ট ২০২৫। Google Stitch ইন্টারফেস বানায়, রিপোজিটরির প্যাচ নয়। এটিও বেরোয় সেই ২০ মে।
আমরা জানতাম যে একটি সদ্য-জন্মানো প্রযুক্তিতে early adopters (“পরীক্ষার বিষয়”) হিসেবে কাজ করছি। নিচের বাজিও স্পষ্ট ছিল: Google আরেকটি স্থানীয় কোড-autocomplete বানাচ্ছিল না। সে গ্রহের সবচেয়ে বড় ক্লাউডকে সফটওয়্যার নির্মাণের নিচে রাখছিল।
2. বাধা: গণনার বাস হিসেবে GitHub
যে প্রকৌশলী একই স্থানীয় মেশিনে ৪ বা ৫টি এজেন্ট একসঙ্গে চালিয়ে কাজ দিয়েছেন, তিনি একই ভৌত দেয়ালে ধাক্কা খান: ফাইলের সংঘর্ষ এবং অবস্থা মুছে যাওয়া। দুটি এজেন্ট স্থানীয়ভাবে একই ফাইল সম্পাদনা করলে কর্মক্ষেত্র নষ্ট হয়।
সেই সময়ে পথ ভার্চুয়াল ফাইল সিস্টেম ছিল না। পথ ছিল যে পাইপলাইন শিল্প আগেই সমাধান করেছিল: GitHub।
┌────────────────────────────────────────────────────────────────────────┐
│ PIPELINE DISTRIBUIDO DE GOOGLE JULES │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ GitHub Issues Google Cloud Compute Pull Requests │
│ ┌──────────────┐ ┌─────────────────────┐ ┌─────────────────┐ │
│ │ Spec atómico │ ────► │ Sandbox Aislado │ ──►│ Diff limpio + │ │
│ │ + Criterios │ │ (Jules Agent Run) │ │ Tests verdes │ │
│ └──────────────┘ └─────────────────────┘ └─────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘প্রবাহকে issue → আলাদা এজেন্ট-কাজ → pull request বানালে, Jules-এর প্রতিটি ইনস্ট্যান্স Google-এর ডেটাসেন্টারে নিজের ক্ষণস্থায়ী কনটেইনারে চলে। এজেন্টরা একে অপরকে বাধা দেয় না।
এই বিচ্ছিন্নতা এই সময়ের: এক এজেন্ট, এক ব্রাঞ্চ, এক pull request। Gestalt VFS, যাতে একাধিক এজেন্ট একই ফাইল সম্পাদনা করে, পরে এসেছে। বন্ধের নিবন্ধ সেই অংশ বলে।
১৫টি সমবর্তী কাজের ছাদ
এই সংখ্যা ১১ জুন ছিল না। এটি আসে ৬ আগস্ট ২০২৫, Jules বেটা ছাড়লে। Google AI Pro-তে সীমা হয় ১৫টি সমবর্তী কাজ। ফ্রি প্ল্যান থাকে ৩-এ। তারপর থেকে তরঙ্গ এই ছাদের বিরুদ্ধে গড়ে: এক এজেন্ট একটি সীমাবদ্ধ মাইলফলক বন্ধ করে, পুরো উপ-সিস্টেম নয়।
সেই প্রকাশনায় Jules ব্যবহার করত Gemini 2.5 Pro। 1M-এর বেশি টোকেনের জানালা একটি crate বা একটি মডিউলের জন্য যথেষ্ট ছিল, তার টাইপ ও পরীক্ষা-সহ, যদি issue পুরো সিস্টেম হওয়ার ভান না করে।
3. বিশৃঙ্খলা থেকে হার্নেস: GitCore এবং ৩০ মিনিটের স্প্রিন্ট
PR বাড়লে অসঙ্গতি এল: context drift, কাটা নির্ভরতা, এবং অনাথ ব্রাঞ্চ। ভাগ্যের ওপর থাকা যেত না।
তখন আমি GitCore-এর চারপাশে ইঞ্জিনিয়ারিং হার্নেস বানাই, এবং প্রক্রিয়াটিকে আনুষ্ঠানিক যাচাইয়ের একটি নিশ্চিত চক্র করি:
- ফিচার ম্যাট্রিক্স (
features.json): প্রতিটি প্রকল্প তার অগ্রগতির শতাংশ এবং যাচাইযোগ্য গ্রহণ-মানদণ্ড ঠিক করে। - ব্রাঞ্চের স্বয়ংক্রিয় পরিষ্কার: প্রতিটি মার্জের পর দূরের ব্রাঞ্চের অবিরত মিল।
- E2E স্যুট এবং কড়া বিল্ড: স্বয়ংক্রিয় পরীক্ষার 100% পাস না হলে কোনো PR অনুমোদিত হয় না।
┌──────────────────────────────────────────────────────────────────┐
│ AI SPRINT LIFECYCLE (OLEADA DE 30 MINUTOS) │
├──────────────────────────────────────────────────────────────────┤
│ 1. Lectura de estado previo en Xavier (Memoria) y features.json │
│ 2. Fragmentación en 3-4 micro-issues por feature (Islas) │
│ 3. Auditoría pre-dispatch (0 colisiones de archivos) │
│ 4. Dispatch paralelo a Jules con label 'jules' (hasta 15 tasks) │
│ 5. Monitoreo asíncrono y resolución de suites de tests │
│ 6. Merge secuencial ordenado: Tipos ➔ Core ➔ API ➔ E2E │
│ 7. Actualización de métricas en features.json y cierre de sprint│
└──────────────────────────────────────────────────────────────────┘সিদ্ধান্ত সঙ্গে সঙ্গে এল: এজেন্টের একটি তরঙ্গ সাজানো ঠিক দুই সপ্তাহের অ্যাজাইল স্প্রিন্ট পরিকল্পনার মতো, তফাত এই যে অনুমান, নির্মাণ, পরীক্ষা এবং ডেলিভারির চক্র চলে ৩০ মিনিটে।
4. বন্ধের পরিমাপ (২৮ আগস্ট ২০২৬)
commit-এর গণনা এই নোটের তারিখে কর্মক্ষেত্রের একটি স্ক্যান। এটি ১১ জুন থেকে আবার গণনা নয়, এবং ঘণ্টা git log থেকে আসে না।
| বাস্তুতন্ত্রের মাপ | মান |
|---|---|
| Jules-এর প্রথম push | ১১ জুন ২০২৫, 02:05 UTC |
| এই ছেদের বন্ধ | ২৮ আগস্ট ২০২৬ (প্রথম push থেকে ৪৪৩ দিন) |
| স্ক্যানে রিপোজিটরি | ৮১টি রিপোজিটরি |
| সেই রিপোজিটরিতে commit | 11,240টি commit |
| তরঙ্গের commit (Jules এবং অন্য এজেন্ট) | 1,391টি commit |
features.json-এ ফিচার |
1,723টি স্পেসিফিকেশন |
| মার্জ হওয়া pull request | 1,000+ PR |
| হাতের কাজের সমতুল্য ঘণ্টা | ~6,250 ঘণ্টা, অনুমান, স্ক্যানের বাইরে |
| গুণক | 6.5x – 8.0x, অনুমান |
সবচেয়ে বেশি এজেন্ট-কার্যকলাপের পাবলিক রিপোজিটরি
নিচের তালিকা শুধু পাবলিক কোড। টেবিলের যোগ এই কোডকে এমন কাজের সঙ্গে মেশায় যা প্রকাশিত নয়। সেই অন্য কাজের নাম নেই, লিঙ্ক নেই, আলাদা গণনা নেই।
- Xavier: মোট 1,922টি commit / Jules-এর 255টি (Rust-এ ভেক্টর কগনিটিভ মেমরি)।
- OrionHealth: মোট 1,243টি commit / Jules-এর 61টি (Flutter-এ অফলাইন-প্রথম স্বাস্থ্য)।
- WorldExams: মোট 844টি commit / Jules-এর 85টি (পরীক্ষার অনুশীলন, অফলাইন-প্রথম)।
- Gestalt: মোট 635টি commit / Jules-এর 200টি (Rust-এ বহু-এজেন্ট অর্কেস্ট্রেটর)।
লোকাল-ফার্স্ট ইনভেন্টরি আছে Shelf-এ।
5. মূল প্যাটার্ন: ক্ষুদ্র-বিভাজন এবং অসংলগ্ন ফাইল-দ্বীপ
১৫টি সমবর্তী এজেন্ট একে অপরকে না মুছে কাজ করুক, তাই হার্নেস দুটি নিয়ম রাখে যা নড়ে না:
A. ক্ষুদ্র-বিভাজন
কোনো issue ১৫০ লাইনের প্রভাব ছাড়ায় না, এবং দুইয়ের বেশি স্থাপত্য-স্তর ছোঁয় না। প্রতিটি বড় ফিচার ভাগ হয়:
[Micro-A]: টাইপ চুক্তি, trait এবং struct।[Micro-B]: বিশুদ্ধ ডোমেন লজিক এবং অ্যালগরিদম।[Micro-C]: ইনপুট/আউটপুট অ্যাডাপ্টার (HTTP, IPC, CLI)।[Micro-D]: ইউনিট টেস্ট স্যুট এবং mock।
B. অসংলগ্ন ফাইল-দ্বীপ
jules লেবেল দিয়ে তরঙ্গ পাঠানোর আগে একটি স্ক্রিপ্ট দেখে যে প্রতিটি issue-কে দেওয়া ফাইলের ছেদ একটি খালি সেট:
# Verificación de Islas de Archivos Disjuntas (Pre-Dispatch QA)
islands = {
'#issue-101': ['crates/core/src/types.rs'],
'#issue-102': ['crates/core/src/codec.rs'],
'#issue-103': ['crates/api/src/routes.rs'],
'#issue-104': ['crates/core/tests/e2e_test.rs'],
}
for i1, f1 in islands.items():
for i2, f2 in islands.items():
if i1 < i2 and set(f1) & set(f2):
raise SystemExit(f"❌ COLISIÓN DETECTADA: {i1} y {i2} tocan {set(f1) & set(f2)}")
print("✅ 100% Islas Disjuntas Verificadas.")6. অবকাঠামোর ত্রয়ী: GitCore, Hermes এবং Xavier
Jules শূন্যে চলে না। পুরো বাস্তুতন্ত্রের জোড় তিনটি স্তম্ভে, যা এই কাজের জন্য বানানো:
┌──────────────────────────────┐
│ XAVIER (Memoria Viva) │
│ Contexto histórico & Vector │
└──────────────┬───────────────┘
│ Context Feed
▼
┌──────────────────┐ ┌──────────────┐ ┌──────────────────┐
│ HERMES GATEWAY │ ───► │ GITCORE CLI │ ───► │ GOOGLE JULES │
│ Despacho Rápido │ │ State Engine │ │ 15 Parallel PRs │
└──────────────────┘ └──────────────┘ └──────────────────┘- GitCore: প্রধান হার্নেস। এটি চুক্তি 1টি issue → 1টি ব্রাঞ্চ → 1টি PR চালায়,
features.jsonআপডেট করে, এবং মার্জের আগে linter চালায়। - Hermes: ডিসপ্যাচার। এটি এজেন্টের জীবনচক্র এবং কোটার সীমা সামলায়।
- Xavier: স্থায়ী কগনিটিভ মেমরি, ভেক্টর অর্থ-অনুসন্ধানসহ। এটি issue-কে মাস আগের স্থাপত্য সিদ্ধান্ত দিয়ে ভরায়।
7. এরপর কী শক্ত করতে হবে
প্রথম push, ১১ জুন ২০২৫, থেকে প্রবাহ এই ৪ জায়গায় শক্ত হচ্ছে:
- CI-তে অর্থগত নিশ্চিতি: একই তরঙ্গের ব্রাঞ্চের মধ্যে টাইপ-সামঞ্জস্য,
main-এ মার্জের আগে। - টাইমআউটের আগাম সতর্কতা: অনুমান করা যে একটি এজেন্ট ভারী কম্পাইলে ১৫ মিনিটের বেশি কাটাবে।
- Xavier-এ তাৎক্ষণিক গ্রহণ: webhook যা প্রতিটি অনুমোদিত PR-এর diff ভেক্টর মেমরিতে সূচিবদ্ধ করে।
- ক্ষণস্থায়ী নেটওয়ার্ক স্যান্ডবক্স: সমবর্তী পরীক্ষা-স্যুটের জন্য সকেট ও পোর্ট আলাদা করা।
8. উপসংহার: প্রকৌশলের নতুন সময়
এই প্রথম বছরের সোজা শিক্ষা: উৎপাদনশীলতার আসল লাফ autocomplete দিয়ে কোড দ্রুত টাইপ করা নয়। এটি এমন কড়া হার্নেস বানানো যা স্বায়ত্ত ঝাঁককে সমান্তরালে চালাতে পারে।
Google Jules, Gemini-র শক্তিতে, এবং GitCore-এর মতো একটি নিশ্চিত হার্নেসে সাজানো, দেখায় যে সঠিক স্থাপত্য-সহ একজন প্রকৌশলী একটি পুরো ইঞ্জিনিয়ারিং দলের তাল, দৃঢ়তা এবং গুণে প্রকল্প চালাতে ও দিতে পারেন।
পড়া চালিয়ে যান
এই পোস্টে বলা ১৫টি সমান্তরাল issue-এর তরঙ্গ (Wave 1, Wave 2, Wave 3)-এর আলাদা নিবন্ধ আছে: Waves: ৩০ মিনিটের স্প্রিন্ট হিসেবে তরঙ্গ এবং Gestalt VFS। সেখানে বলি কেন ৩০ মিনিট × N তরঙ্গ ক্লাসিক স্প্রিন্টকে হারায়, এবং Gestalt VFS-কে সেই প্রমাণ হিসেবে রাখি যা সমান্তরালতার ছাদ ভাঙে (একই ফাইলে অনেক এজেন্ট, Rust-এ মার্জ)।
On 11 June 2025, at 02:05 UTC, Jules made the first push on my account. The pull request was merged at 03:50 UTC that same day. Jules had been in public beta since Google I/O on 20 May. The first change that carried a feature landed 22 minutes later, in the same pull request.
By 28 August 2026, with 11,240 commits counted across 81 repositories, the flow is no longer a chat. It is an asynchronous, deterministic software factory that dispatches waves of up to 15 parallel micro-tasks to Google Jules, coordinated by Hermes and checked by the GitCore state machine.
This is the technical retrospective of that stretch: how the tools evolved, how context collisions were avoided, the metrics at the close, and what I learned.
1. The start: a minimalist stance and the first tools
By June 2025 I was already trying coding agents locally. The cut was that first Jules push, not an IDE. Google Antigravity did not exist: it shipped on 18 November 2025, the same day as Gemini 3, as an IDE with agents. The waves in this note are dispatched by Jules.
My technical stance is still minimalist:
Minimum-friction principle: The fewer tools, extensions, and intermediate settings you pile up, the more productive you are. Less time lost arguing about which editor to use, and more time on the problem.
That spring Google Labs had two different things. Jules is the asynchronous agent: it clones the repo in a VM and returns a pull request. It was in public beta from 20 May to 6 August 2025. Google Stitch generates an interface, not patches for a repository. It shipped the same 20 May.
We knew we were operating as early adopters (“guinea pigs”) on a technology that was just being born. The underlying bet was also clear: Google was not trying to build another local code autocomplete. It was putting the largest cloud on the planet under software development.
2. The bottleneck: GitHub as the compute bus
Any engineer who has tried to hand work to 4 or 5 agents running at once on the same local machine hits the same physical wall: file collisions and overwritten state. Two agents editing the same file locally destroy the workspace.
In that stretch the way out was not a virtual filesystem. It was the pipeline the industry had already solved: GitHub.
┌────────────────────────────────────────────────────────────────────────┐
│ PIPELINE DISTRIBUIDO DE GOOGLE JULES │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ GitHub Issues Google Cloud Compute Pull Requests │
│ ┌──────────────┐ ┌─────────────────────┐ ┌─────────────────┐ │
│ │ Spec atómico │ ────► │ Sandbox Aislado │ ──►│ Diff limpio + │ │
│ │ + Criterios │ │ (Jules Agent Run) │ │ Tests verdes │ │
│ └──────────────┘ └─────────────────────┘ └─────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘Turning the flow into issue → isolated agent task → pull request, each Jules instance runs in its own ephemeral container on Google’s datacenters, so agents do not interfere with each other.
That isolation is the one for this stretch: one branch and one pull request per agent. Gestalt VFS, so that several agents can edit the same file, came later. The closing article tells that part.
The ceiling of 15 concurrent tasks
That number did not exist on 11 June. It arrived on 6 August 2025, when Jules left beta. On Google AI Pro the cap became 15 concurrent tasks. The free plan stayed at 3. From then on, waves are built against that ceiling: one agent closes a bounded milestone, not a whole subsystem.
At that launch Jules used Gemini 2.5 Pro. A window of more than 1M tokens was enough for a crate or a module, with its types and its tests, if the issue did not pretend to be the whole system.
3. From chaos to a harness: GitCore and 30-minute sprints
As the volume of PRs grew, anomalies showed up: context drift, crossed dependencies, and orphan branches. We could not depend on luck.
That is when I built the engineering harness around GitCore, and turned the process into a deterministic cycle of formal verification:
- Feature matrix (
features.json): each project defines its percentage of progress and acceptance criteria that can be checked. - Automated branch cleanup: continuous reconciliation of remote branches after every merge.
- E2E suites and a strict build: no PR is approved unless it passes 100% of the automated test suite.
┌──────────────────────────────────────────────────────────────────┐
│ AI SPRINT LIFECYCLE (OLEADA DE 30 MINUTOS) │
├──────────────────────────────────────────────────────────────────┤
│ 1. Lectura de estado previo en Xavier (Memoria) y features.json │
│ 2. Fragmentación en 3-4 micro-issues por feature (Islas) │
│ 3. Auditoría pre-dispatch (0 colisiones de archivos) │
│ 4. Dispatch paralelo a Jules con label 'jules' (hasta 15 tasks) │
│ 5. Monitoreo asíncrono y resolución de suites de tests │
│ 6. Merge secuencial ordenado: Tipos ➔ Core ➔ API ➔ E2E │
│ 7. Actualización de métricas en features.json y cierre de sprint│
└──────────────────────────────────────────────────────────────────┘The realization was immediate: organizing a wave of agents is exactly like planning a two-week agile sprint, except the cycle of estimation, development, testing, and delivery runs in 30 minutes.
4. Metrics at the close (28 August 2026)
The commit counts are a workspace scan at the date of this note. They are not a recount from 11 June, and the hours do not come from git log.
| Ecosystem metric | Value |
|---|---|
| First Jules push | 11 June 2025, 02:05 UTC |
| Close of this cut | 28 August 2026 (443 days since the first push) |
| Repositories in the scan | 81 repositories |
| Commits in those repositories | 11,240 commits |
| Wave commits (Jules and other agents) | 1,391 commits |
Features in features.json |
1,723 specifications |
| Merged pull requests | 1,000+ PRs |
| Equivalent hours of manual work | ~6,250 h, an estimate, outside the scan |
| Multiplier | 6.5x – 8.0x, an estimate |
Public repositories with the most agent activity
The list below is public code only. The totals in the table mix that code with other work that is not published. That other work has no name, no link, and no count.
- Xavier: 1,922 total commits / 255 Jules commits (vector cognitive memory in Rust).
- OrionHealth: 1,243 total commits / 61 Jules commits (offline-first health in Flutter).
- WorldExams: 844 total commits / 85 Jules commits (exam practice, offline-first).
- Gestalt: 635 total commits / 200 Jules commits (multi-agent orchestrator in Rust).
The local-first inventory is at Shelf.
5. Key patterns: micro-fragmentation and disjoint file islands
To let 15 concurrent agents work without destroying each other, the harness implements two rules that do not bend:
A. Micro-fragmentation
No issue exceeds 150 lines of impact or spans more than two architectural layers. Each large feature is split into:
[Micro-A]: type contracts, traits, and structs.[Micro-B]: pure domain logic and algorithms.[Micro-C]: input/output adapters (HTTP, IPC, CLI).[Micro-D]: unit-test suites and mocks.
B. Disjoint file islands
Before dispatching a wave with the jules label, a script checks that the intersection of files assigned to each issue is an empty set:
# Verificación de Islas de Archivos Disjuntas (Pre-Dispatch QA)
islands = {
'#issue-101': ['crates/core/src/types.rs'],
'#issue-102': ['crates/core/src/codec.rs'],
'#issue-103': ['crates/api/src/routes.rs'],
'#issue-104': ['crates/core/tests/e2e_test.rs'],
}
for i1, f1 in islands.items():
for i2, f2 in islands.items():
if i1 < i2 and set(f1) & set(f2):
raise SystemExit(f"❌ COLISIÓN DETECTADA: {i1} y {i2} tocan {set(f1) & set(f2)}")
print("✅ 100% Islas Disjuntas Verificadas.")6. The infrastructure triad: GitCore, Hermes, and Xavier
Jules does not run in a vacuum. The whole ecosystem hangs on three pillars built for this:
┌──────────────────────────────┐
│ XAVIER (Memoria Viva) │
│ Contexto histórico & Vector │
└──────────────┬───────────────┘
│ Context Feed
▼
┌──────────────────┐ ┌──────────────┐ ┌──────────────────┐
│ HERMES GATEWAY │ ───► │ GITCORE CLI │ ───► │ GOOGLE JULES │
│ Despacho Rápido │ │ State Engine │ │ 15 Parallel PRs │
└──────────────────┘ └──────────────┘ └──────────────────┘- GitCore: the master harness. It governs the contract 1 issue → 1 branch → 1 PR, updates
features.json, and runs the pre-merge linters. - Hermes: the dispatcher. It manages the agent lifecycle and the quota limits.
- Xavier: persistent cognitive memory with vector semantic search. It feeds issues with architectural decisions made months earlier.
7. What to improve next
Since the first push, on 11 June 2025, these are the 4 areas where the flow is being tightened:
- Semantic assertion in CI: check type compatibility across branches of the same wave before merging to
main. - Early timeout alerts: predict when an agent spends more than 15 minutes on a heavy compile.
- Realtime ingestion into Xavier: webhooks that index the diff of every approved PR into vector memory.
- Ephemeral network sandboxing: isolate sockets and ports for concurrent test suites.
8. Conclusion: the new era of engineering
The hard lesson of this first year: the real productivity jump is not typing code faster with autocomplete. It is designing strict harnesses that can run autonomous swarms in parallel.
Google Jules, backed by Gemini and orchestrated by a deterministic harness like GitCore, showed that one engineer with the right architecture can lead and ship projects with the cadence, the robustness, and the quality of a full engineering team.
Keep reading
The waves of 15 parallel issues mentioned in this post (Wave 1, Wave 2, Wave 3) have their own article: Waves: waves as 30-minute sprints and Gestalt VFS. There I explain why 30 min × N waves beats the classic sprint, and I present Gestalt VFS as the proof of concept that breaks the parallelism ceiling (many agents on the same file, merge in Rust).
Le 11 juin 2025, à 02:05 UTC, Jules a fait le premier push sur mon compte. La pull request a été mergée à 03:50 UTC le même jour. Jules était en bêta publique depuis le Google I/O du 20 mai. Le premier changement qui portait une feature est arrivé 22 minutes plus tard, dans la même pull request.
Au 28 août 2026, avec 11 240 commits comptés dans 81 dépôts, le flux n’est plus un chat. C’est une usine logicielle asynchrone et déterministe qui envoie des vagues de jusqu’à 15 micro-tâches parallèles à Google Jules, coordonnées par Hermes et vérifiées par la machine d’états de GitCore.
Voici la rétrospective technique de cette période : l’évolution des outils, les parades aux collisions de contexte, les métriques de clôture et ce que j’en ai retenu.
1. Le début : une posture minimaliste et les premiers outils
En juin 2025, j’expérimentais déjà des agents de code en local. La coupure, c’est ce premier push de Jules, pas un IDE. Google Antigravity n’existait pas : il est sorti le 18 novembre 2025, le même jour que Gemini 3, comme IDE avec agents. Les vagues de cette note sont envoyées par Jules.
Ma posture technique reste minimaliste :
Principe de friction minimale : Moins vous empilez d’outils, d’extensions et de réglages intermédiaires, plus vous êtes productif. Moins de temps perdu à débattre de l’éditeur, plus de temps sur le problème.
Ce printemps-là, Google Labs avait deux choses distinctes. Jules est l’agent asynchrone : il clone le dépôt dans une VM et rend une pull request. Il est resté en bêta publique du 20 mai au 6 août 2025. Google Stitch génère une interface, pas des correctifs sur un dépôt. Il est sorti le même 20 mai.
Nous savions que nous opérions en early adopters (« cobayes ») sur une technologie naissante. Le pari de fond était tout aussi net : Google ne cherchait pas un autre autocomplétion locale. Il mettait le plus grand cloud de la planète sous le développement logiciel.
2. Le goulet : GitHub comme bus de calcul
Tout ingénieur qui a confié du travail à 4 ou 5 agents lancés en même temps sur une seule machine locale bute sur le même mur physique : les collisions de fichiers et l’écrasement de l’état. Deux agents qui éditent le même fichier en local détruisent l’espace de travail.
Dans cette période, la sortie n’a pas été un système de fichiers virtuel. C’était le pipeline que l’industrie avait déjà résolu : GitHub.
┌────────────────────────────────────────────────────────────────────────┐
│ PIPELINE DISTRIBUIDO DE GOOGLE JULES │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ GitHub Issues Google Cloud Compute Pull Requests │
│ ┌──────────────┐ ┌─────────────────────┐ ┌─────────────────┐ │
│ │ Spec atómico │ ────► │ Sandbox Aislado │ ──►│ Diff limpio + │ │
│ │ + Criterios │ │ (Jules Agent Run) │ │ Tests verdes │ │
│ └──────────────┘ └─────────────────────┘ └─────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘En transformant le flux en issue → tâche d’agent isolée → pull request, chaque instance de Jules tourne dans son propre conteneur éphémère, dans les datacenters de Google. Les agents ne se gênent plus.
Cet isolement est celui de cette période : une branche et une pull request par agent. Gestalt VFS, pour que plusieurs agents éditent le même fichier, est venu après. L’article de clôture raconte cette partie.
Le plafond de 15 tâches concurrentes
Ce nombre n’existait pas le 11 juin. Il est arrivé le 6 août 2025, quand Jules est sorti de bêta. Sur Google AI Pro, le quota est devenu 15 tâches concurrentes. Le plan gratuit est resté à 3. Depuis, les vagues se montent contre ce plafond : un agent ferme un jalon borné, pas un sous-système entier.
À cette sortie, Jules utilisait Gemini 2.5 Pro. Une fenêtre de plus de 1M de tokens suffisait pour un crate ou un module, avec ses types et ses tests, si l’issue ne prétendait pas être le système complet.
3. Du chaos au harnais : GitCore et les sprints de 30 minutes
Quand le volume de PR a grandi, les anomalies sont apparues : context drift, dépendances croisées et branches orphelines. On ne pouvait pas compter sur la chance.
C’est là que j’ai construit le harnais d’ingénierie autour de GitCore, et transformé le processus en cycle déterministe de vérification formelle :
- Matrice de features (
features.json) : chaque projet définit son avancement en pourcentage et des critères d’acceptation vérifiables. - Nettoyage automatisé des branches : réconciliation continue des branches distantes après chaque merge.
- Suites E2E et compilation stricte : aucune PR n’est approuvée si elle ne passe pas 100 % de la suite de tests automatisés.
┌──────────────────────────────────────────────────────────────────┐
│ AI SPRINT LIFECYCLE (OLEADA DE 30 MINUTOS) │
├──────────────────────────────────────────────────────────────────┤
│ 1. Lectura de estado previo en Xavier (Memoria) y features.json │
│ 2. Fragmentación en 3-4 micro-issues por feature (Islas) │
│ 3. Auditoría pre-dispatch (0 colisiones de archivos) │
│ 4. Dispatch paralelo a Jules con label 'jules' (hasta 15 tasks) │
│ 5. Monitoreo asíncrono y resolución de suites de tests │
│ 6. Merge secuencial ordenado: Tipos ➔ Core ➔ API ➔ E2E │
│ 7. Actualización de métricas en features.json y cierre de sprint│
└──────────────────────────────────────────────────────────────────┘Le constat a été immédiat : organiser une vague d’agents, c’est exactement planifier un sprint agile de deux semaines, à ceci près que le cycle d’estimation, de développement, de test et de livraison tient en 30 minutes.
4. Métriques à la clôture (28 août 2026)
Les comptes de commits sont un scan du workspace à la date de cette note. Ce n’est pas un recomptage depuis le 11 juin, et les heures ne sortent pas de git log.
| Métrique de l’écosystème | Valeur |
|---|---|
| Premier push de Jules | 11 juin 2025, 02:05 UTC |
| Clôture de cette coupe | 28 août 2026 (443 jours depuis le premier push) |
| Dépôts dans le scan | 81 dépôts |
| Commits dans ces dépôts | 11 240 commits |
| Commits de vagues (Jules et d’autres agents) | 1 391 commits |
Features dans features.json |
1 723 spécifications |
| Pull requests mergées | 1 000+ PR |
| Heures équivalentes de travail manuel | ~6 250 h, une estimation, hors du scan |
| Multiplicateur | 6,5x – 8,0x, une estimation |
Dépôts publics avec le plus d’activité d’agents
La liste ci-dessous ne contient que du code public. Les totaux du tableau mélangent ce code avec un autre travail qui n’est pas publié. Cet autre travail n’a ni nom, ni lien, ni compte.
- Xavier : 1 922 commits au total / 255 commits de Jules (mémoire cognitive vectorielle en Rust).
- OrionHealth : 1 243 commits au total / 61 commits de Jules (santé offline-first en Flutter).
- WorldExams : 844 commits au total / 85 commits de Jules (pratique d’examens, offline-first).
- Gestalt : 635 commits au total / 200 commits de Jules (orchestrateur multi-agent en Rust).
L’inventaire local-first est sur Shelf.
5. Motifs clés : micro-fragmentation et îlots de fichiers disjoints
Pour que 15 agents concurrents travaillent sans se détruire, le harnais applique deux règles qui ne plient pas :
A. Micro-fragmentation
Aucune issue ne dépasse 150 lignes d’impact ni plus de deux couches d’architecture. Chaque grande feature est découpée en :
[Micro-A]: contrats de types, traits et structs.[Micro-B]: logique de domaine pure et algorithmes.[Micro-C]: adaptateurs d’entrée/sortie (HTTP, IPC, CLI).[Micro-D]: suites de tests unitaires et mocks.
B. Îlots de fichiers disjoints
Avant d’envoyer une vague avec le label jules, un script vérifie que l’intersection des fichiers assignés à chaque issue est un ensemble vide :
# Verificación de Islas de Archivos Disjuntas (Pre-Dispatch QA)
islands = {
'#issue-101': ['crates/core/src/types.rs'],
'#issue-102': ['crates/core/src/codec.rs'],
'#issue-103': ['crates/api/src/routes.rs'],
'#issue-104': ['crates/core/tests/e2e_test.rs'],
}
for i1, f1 in islands.items():
for i2, f2 in islands.items():
if i1 < i2 and set(f1) & set(f2):
raise SystemExit(f"❌ COLISIÓN DETECTADA: {i1} y {i2} tocan {set(f1) & set(f2)}")
print("✅ 100% Islas Disjuntas Verificadas.")6. La triade d’infrastructure : GitCore, Hermes et Xavier
Jules ne tourne pas dans le vide. Tout l’écosystème tient sur trois piliers faits pour ça :
┌──────────────────────────────┐
│ XAVIER (Memoria Viva) │
│ Contexto histórico & Vector │
└──────────────┬───────────────┘
│ Context Feed
▼
┌──────────────────┐ ┌──────────────┐ ┌──────────────────┐
│ HERMES GATEWAY │ ───► │ GITCORE CLI │ ───► │ GOOGLE JULES │
│ Despacho Rápido │ │ State Engine │ │ 15 Parallel PRs │
└──────────────────┘ └──────────────┘ └──────────────────┘- GitCore : le harnais maître. Il gouverne le contrat 1 issue → 1 branche → 1 PR, met à jour
features.jsonet lance les linters avant le merge. - Hermes : le dispatcher. Il gère le cycle de vie des agents et les plafonds de quota.
- Xavier : mémoire cognitive persistante avec recherche sémantique vectorielle. Il nourrit les issues avec des décisions d’architecture prises des mois plus tôt.
7. Ce qu’il reste à serrer
Depuis le premier push, le 11 juin 2025, le flux se resserre sur 4 points :
- Assertion sémantique en CI : vérifier la compatibilité des types entre les branches d’une même vague avant le merge vers
main. - Alertes précoces de timeout : prédire qu’un agent dépasse 15 minutes sur une compilation lourde.
- Ingestion en temps réel dans Xavier : des webhooks qui indexent le diff de chaque PR approuvée dans la mémoire vectorielle.
- Sandbox réseau éphémère : isoler sockets et ports pour les suites de tests concurrentes.
8. Conclusion : la nouvelle ère de l’ingénierie
La leçon nette de cette première année : le vrai saut de productivité n’est pas de taper du code plus vite avec une autocomplétion. C’est de concevoir des harnais stricts capables de faire tourner des essaims autonomes en parallèle.
Google Jules, porté par Gemini et orchestré par un harnais déterministe comme GitCore, a montré qu’un seul ingénieur, avec la bonne architecture, peut mener et livrer des projets avec la cadence, la robustesse et la qualité d’une équipe d’ingénierie complète.
Continuer la lecture
Les vagues de 15 issues parallèles citées dans ce post (Wave 1, Wave 2, Wave 3) ont un article à part : Waves : les vagues comme sprints de 30 minutes et Gestalt VFS. J’y explique pourquoi 30 min × N vagues bat le sprint classique, et je présente Gestalt VFS comme la preuve de concept qui casse le plafond de parallélisme (plusieurs agents sur le même fichier, merge en Rust).
11 जून 2025, 02:05 UTC पर Jules ने मेरे खाते में पहला push किया। उसी दिन 03:50 UTC पर pull request मर्ज हुआ। Jules 20 मई के Google I/O से सार्वजनिक बीटा में था। फ़ीचर वाला पहला बदलाव 22 मिनट बाद आया, उसी pull request में।
28 अगस्त 2026 तक, 81 रिपॉज़िटरी में गिने 11,240 commits के साथ, प्रवाह अब चैट नहीं रहा। यह एक असिंक्रोनस, निर्धारक सॉफ़्टवेयर फ़ैक्टरी है, जो Google Jules को अधिकतम 15 समानांतर सूक्ष्म-कार्यों की लहरें भेजती है। समन्वय Hermes करता है, और जाँच GitCore की स्टेट मशीन करती है।
यह उस अवधि की तकनीकी समीक्षा है: उपकरण कैसे बदले, संदर्भ की टक्कर कैसे टाली गई, समापन के आँकड़े, और क्या सीखा।
1. शुरुआत: न्यूनतम रुख और पहले उपकरण
जून 2025 तक मैं स्थानीय कोडिंग एजेंट आज़मा चुका था। कटाव उस पहले Jules push पर हुआ, किसी IDE पर नहीं। Google Antigravity तब था ही नहीं: वह 18 नवंबर 2025 को आया, Gemini 3 के उसी दिन, एजेंटों वाला IDE बनकर। इस नोट की लहरें Jules भेजता है।
तकनीकी रुख अब भी न्यूनतम है:
न्यूनतम घर्षण का सिद्धांत: जितने कम उपकरण, एक्सटेंशन और बीच की सेटिंग्स जमा करोगे, उतने अधिक उत्पादक रहोगे। कौन-सा एडिटर चुनें, इस बहस में कम समय, और समस्या पर अधिक समय।
उस बसंत Google Labs के पास दो अलग चीज़ें थीं। Jules असिंक्रोनस एजेंट है: VM में रिपो क्लोन करता है और pull request लौटाता है। सार्वजनिक बीटा 20 मई से 6 अगस्त 2025 तक रहा। Google Stitch इंटरफ़ेस बनाता है, रिपॉज़िटरी का पैच नहीं। वह भी उसी 20 मई को आया।
हमें पता था कि हम एक नई तकनीक पर early adopters (“प्रयोग के विषय”) की तरह काम कर रहे थे। नीचे की शर्त भी साफ़ थी: Google एक और स्थानीय कोड-autocomplete नहीं बना रहा था। वह ग्रह के सबसे बड़े क्लाउड को सॉफ़्टवेयर विकास के नीचे रख रहा था।
2. अड़चन: गणना की बस के रूप में GitHub
जिस इंजीनियर ने एक ही स्थानीय मशीन पर 4 या 5 एजेंट एक साथ चलाकर काम सौंपा है, वह उसी भौतिक दीवार से टकराता है: फ़ाइल टकराव और अवस्था का मिट जाना। दो एजेंट स्थानीय रूप से एक ही फ़ाइल संपादित करें, तो कार्यक्षेत्र नष्ट हो जाता है।
उस अवधि में रास्ता वर्चुअल फ़ाइल सिस्टम नहीं था। वह पाइपलाइन थी जिसे उद्योग पहले ही सुलझा चुका था: GitHub।
┌────────────────────────────────────────────────────────────────────────┐
│ PIPELINE DISTRIBUIDO DE GOOGLE JULES │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ GitHub Issues Google Cloud Compute Pull Requests │
│ ┌──────────────┐ ┌─────────────────────┐ ┌─────────────────┐ │
│ │ Spec atómico │ ────► │ Sandbox Aislado │ ──►│ Diff limpio + │ │
│ │ + Criterios │ │ (Jules Agent Run) │ │ Tests verdes │ │
│ └──────────────┘ └─────────────────────┘ └─────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘प्रवाह को issue → अलग एजेंट कार्य → pull request बनाने पर, Jules का हर उदाहरण Google के डेटा सेंटर में अपने अल्पकालिक कंटेनर में चलता है। एजेंट एक-दूसरे से टकराते नहीं।
यह अलगाव इसी अवधि का है: एक एजेंट, एक ब्रांच, एक pull request। Gestalt VFS, जिससे कई एजेंट एक ही फ़ाइल संपादित कर सकें, बाद में आया। समापन वाला लेख वह हिस्सा बताता है।
15 समवर्ती कार्यों की छत
यह संख्या 11 जून को थी ही नहीं। वह 6 अगस्त 2025 को आई, जब Jules बीटा से बाहर आया। Google AI Pro पर सीमा 15 समवर्ती कार्य हुई। मुफ़्त योजना 3 पर रही। तब से लहरें इसी छत के विरुद्ध बनती हैं: एक एजेंट एक घिरा हुआ मील का पत्थर बंद करता है, पूरा उपतंत्र नहीं।
उस रिलीज़ में Jules Gemini 2.5 Pro इस्तेमाल करता था। 1M से अधिक टोकन की खिड़की एक crate या एक मॉड्यूल के लिए काफ़ी थी, उसके प्रकारों और परीक्षणों समेत, अगर issue पूरे सिस्टम होने का दावा न करे।
3. अराजकता से हार्नेस तक: GitCore और 30 मिनट के स्प्रिंट
PR बढ़े, तो विसंगतियाँ आईं: context drift, कटी निर्भरताएँ, और अनाथ ब्रांच। किस्मत पर निर्भर नहीं रहा जा सकता था।
तभी मैंने GitCore के चारों ओर इंजीनियरिंग हार्नेस बनाया, और प्रक्रिया को औपचारिक जाँच का निर्धारक चक्र बना दिया:
- फ़ीचर मैट्रिक्स (
features.json): हर परियोजना अपनी प्रगति का प्रतिशत और जाँचे जा सकने वाले स्वीकृति मानदंड तय करती है। - ब्रांच की स्वचालित सफ़ाई: हर मर्ज के बाद दूरस्थ ब्रांच का निरंतर मेल।
- E2E सूट और सख्त बिल्ड: स्वचालित परीक्षण सूट का 100% पास हुए बिना कोई PR मंजूर नहीं होता।
┌──────────────────────────────────────────────────────────────────┐
│ AI SPRINT LIFECYCLE (OLEADA DE 30 MINUTOS) │
├──────────────────────────────────────────────────────────────────┤
│ 1. Lectura de estado previo en Xavier (Memoria) y features.json │
│ 2. Fragmentación en 3-4 micro-issues por feature (Islas) │
│ 3. Auditoría pre-dispatch (0 colisiones de archivos) │
│ 4. Dispatch paralelo a Jules con label 'jules' (hasta 15 tasks) │
│ 5. Monitoreo asíncrono y resolución de suites de tests │
│ 6. Merge secuencial ordenado: Tipos ➔ Core ➔ API ➔ E2E │
│ 7. Actualización de métricas en features.json y cierre de sprint│
└──────────────────────────────────────────────────────────────────┘निष्कर्ष तुरंत आया: एजेंटों की लहर संगठित करना ठीक दो सप्ताह के एजाइल स्प्रिंट की योजना जैसा है, फ़र्क यह है कि अनुमान, विकास, परीक्षण और डिलीवरी का चक्र 30 मिनट में चलता है।
4. समापन के आँकड़े (28 अगस्त 2026)
commit की गिनती इस नोट की तारीख पर कार्यक्षेत्र का स्कैन है। यह 11 जून से दोबारा गिनती नहीं है, और घंटे git log से नहीं आते।
| पारिस्थितिकी का माप | मान |
|---|---|
| Jules का पहला push | 11 जून 2025, 02:05 UTC |
| इस कटाव का समापन | 28 अगस्त 2026 (पहले push से 443 दिन) |
| स्कैन में रिपॉज़िटरी | 81 रिपॉज़िटरी |
| उन रिपॉज़िटरी में commits | 11,240 commits |
| लहरों के commits (Jules और अन्य एजेंट) | 1,391 commits |
features.json में फ़ीचर |
1,723 विनिर्देश |
| मर्ज हुए pull request | 1,000+ PR |
| हाथ के काम के समतुल्य घंटे | ~6,250 घंटे, अनुमान, स्कैन के बाहर |
| गुणक | 6.5x – 8.0x, अनुमान |
सबसे अधिक एजेंट गतिविधि वाले सार्वजनिक रिपॉज़िटरी
नीचे की सूची केवल सार्वजनिक कोड है। तालिका के योग उस कोड को ऐसे काम से मिलाते हैं जो प्रकाशित नहीं है। उस दूसरे काम का न नाम है, न लिंक, न अलग गिनती।
- Xavier: कुल 1,922 commits / Jules के 255 (Rust में वेक्टर संज्ञानात्मक मेमोरी)।
- OrionHealth: कुल 1,243 commits / Jules के 61 (Flutter में ऑफ़लाइन-प्रथम स्वास्थ्य)।
- WorldExams: कुल 844 commits / Jules के 85 (परीक्षा अभ्यास, ऑफ़लाइन-प्रथम)।
- Gestalt: कुल 635 commits / Jules के 200 (Rust में बहु-एजेंट ऑर्केस्ट्रेटर)।
लोकल-फ़र्स्ट इन्वेंटरी Shelf पर है।
5. मुख्य पैटर्न: सूक्ष्म-विभाजन और असंयुक्त फ़ाइल द्वीप
15 समवर्ती एजेंट एक-दूसरे को मिटाए बिना काम करें, इसके लिए हार्नेस दो नियम रखता है जो झुकते नहीं:
A. सूक्ष्म-विभाजन
कोई issue 150 पंक्तियों के प्रभाव से आगे नहीं जाता, और दो से अधिक वास्तुकला परतों को नहीं छूता। हर बड़ा फ़ीचर बँटता है:
[Micro-A]: प्रकार अनुबंध, trait और struct।[Micro-B]: शुद्ध डोमेन तर्क और एल्गोरिदम।[Micro-C]: इनपुट/आउटपुट अडैप्टर (HTTP, IPC, CLI)।[Micro-D]: यूनिट परीक्षण सूट और mock।
B. असंयुक्त फ़ाइल द्वीप
jules लेबल के साथ लहर भेजने से पहले एक स्क्रिप्ट जाँचती है कि हर issue को दिए फ़ाइलों का प्रतिच्छेद खाली समुच्चय है:
# Verificación de Islas de Archivos Disjuntas (Pre-Dispatch QA)
islands = {
'#issue-101': ['crates/core/src/types.rs'],
'#issue-102': ['crates/core/src/codec.rs'],
'#issue-103': ['crates/api/src/routes.rs'],
'#issue-104': ['crates/core/tests/e2e_test.rs'],
}
for i1, f1 in islands.items():
for i2, f2 in islands.items():
if i1 < i2 and set(f1) & set(f2):
raise SystemExit(f"❌ COLISIÓN DETECTADA: {i1} y {i2} tocan {set(f1) & set(f2)}")
print("✅ 100% Islas Disjuntas Verificadas.")6. अवसंरचना की त्रयी: GitCore, Hermes और Xavier
Jules खाली जगह में नहीं चलता। पूरे पारिस्थितिकी तंत्र का जोड़ तीन स्तंभों पर है, जो इसी के लिए बने:
┌──────────────────────────────┐
│ XAVIER (Memoria Viva) │
│ Contexto histórico & Vector │
└──────────────┬───────────────┘
│ Context Feed
▼
┌──────────────────┐ ┌──────────────┐ ┌──────────────────┐
│ HERMES GATEWAY │ ───► │ GITCORE CLI │ ───► │ GOOGLE JULES │
│ Despacho Rápido │ │ State Engine │ │ 15 Parallel PRs │
└──────────────────┘ └──────────────┘ └──────────────────┘- GitCore: मुख्य हार्नेस। यह अनुबंध 1 issue → 1 ब्रांच → 1 PR चलाता है,
features.jsonअपडेट करता है, और मर्ज से पहले linter चलाता है। - Hermes: डिस्पैचर। यह एजेंटों का जीवन-चक्र और कोटे की सीमाएँ संभालता है।
- Xavier: स्थायी संज्ञानात्मक मेमोरी, वेक्टर अर्थ-खोज के साथ। यह issue को महीनों पहले लिए गए वास्तुकला निर्णयों से भरता है।
7. आगे क्या कसना है
पहले push, 11 जून 2025, के बाद प्रवाह इन 4 जगहों पर कसा जा रहा है:
- CI में अर्थगत जाँच: एक ही लहर की ब्रांचों के बीच प्रकार-संगति,
mainपर मर्ज से पहले। - टाइमआउट की जल्दी चेतावनी: अनुमान कि कोई एजेंट भारी संकलन पर 15 मिनट से अधिक लगाएगा।
- Xavier में वास्तविक-समय अंतर्ग्रहण: webhook जो हर स्वीकृत PR के diff को वेक्टर मेमोरी में अनुक्रमित करें।
- अल्पकालिक नेटवर्क सैंडबॉक्स: समवर्ती परीक्षण सूट के लिए सॉकेट और पोर्ट का अलगाव।
8. निष्कर्ष: इंजीनियरिंग का नया दौर
इस पहले साल का सीधा सबक: उत्पादकता की असली छलांग autocomplete से कोड तेज़ी से टाइप करना नहीं है। यह ऐसे सख्त हार्नेस बनाना है जो स्वायत्त झुंड को समानांतर चला सकें।
Google Jules, Gemini की शक्ति पर, और GitCore जैसे निर्धारक हार्नेस से संचालित, यह दिखाता है कि सही वास्तुकला वाला एक इंजीनियर पूरी इंजीनियरिंग टीम की लय, मज़बूती और गुणवत्ता के साथ परियोजनाएँ ले जा सकता है और सौंप सकता है।
आगे पढ़ें
इस पोस्ट में कही 15 समानांतर issue की लहरों (Wave 1, Wave 2, Wave 3) का अलग लेख है: Waves: 30 मिनट के स्प्रिंट के रूप में लहरें और Gestalt VFS। वहाँ मैं बताता हूँ कि 30 मिनट × N लहरें क्लासिक स्प्रिंट को क्यों मात देती हैं, और Gestalt VFS को उस प्रमाण के रूप में रखता हूँ जो समानांतरता की छत तोड़ता है (एक ही फ़ाइल पर कई एजेंट, Rust में मर्ज)।
Em 11 de junho de 2025, às 02:05 UTC, o Jules fez o primeiro push na minha conta. O pull request foi mergeado às 03:50 UTC desse mesmo dia. O Jules estava em beta pública desde o Google I/O de 20 de maio. A primeira mudança com uma feature chegou 22 minutos depois, no mesmo pull request.
Em 28 de agosto de 2026, com 11.240 commits contados em 81 repositórios, o fluxo já não é um chat. É uma fábrica de software assíncrona e determinista que despacha ondas de até 15 microtarefas paralelas para o Google Jules, coordenadas pelo Hermes e verificadas pela máquina de estados do GitCore.
Esta é a retrospectiva técnica desse trecho: a evolução das ferramentas, as saídas para evitar colisões de contexto, as métricas do fechamento e o que ficou de aprendizado.
1. O começo: postura minimalista e as primeiras ferramentas
Em junho de 2025 eu já experimentava agentes de código em local. O corte foi aquele primeiro push do Jules, não um IDE. O Google Antigravity não existia: saiu em 18 de novembro de 2025, no mesmo dia do Gemini 3, como IDE com agentes. As ondas desta nota são despachadas pelo Jules.
A postura técnica continua minimalista:
Princípio de fricção mínima: Quanto menos ferramentas, extensões e configurações intermediárias você acumula, mais produtivo você é. Menos tempo perdido discutindo qual editor usar e mais tempo no problema.
Naquela primavera o Google Labs tinha duas coisas distintas. Jules é o agente assíncrono: clona o repositório numa VM e devolve um pull request. Ficou em beta pública de 20 de maio a 6 de agosto de 2025. O Google Stitch gera interface, não patches de um repositório. Saiu no mesmo 20 de maio.
Sabíamos que operávamos como early adopters (“cobaias”) numa tecnologia que nascia. A aposta de fundo também era clara: o Google não estava tentando criar mais um autocompletar de código local, e sim pôr a maior nuvem do planeta debaixo do desenvolvimento de software.
2. O gargalo: GitHub como barramento de computação
Qualquer engenheiro que tenha tentado delegar trabalho a 4 ou 5 agentes rodando ao mesmo tempo numa máquina local esbarra no mesmo muro físico: colisões de arquivos e sobrescrita de estado. Dois agentes editando o mesmo arquivo em local destroem o espaço de trabalho.
Nesse trecho a saída não foi um sistema de arquivos virtual. Foi o pipeline que a indústria já tinha resolvido: GitHub.
┌────────────────────────────────────────────────────────────────────────┐
│ PIPELINE DISTRIBUIDO DE GOOGLE JULES │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ GitHub Issues Google Cloud Compute Pull Requests │
│ ┌──────────────┐ ┌─────────────────────┐ ┌─────────────────┐ │
│ │ Spec atómico │ ────► │ Sandbox Aislado │ ──►│ Diff limpio + │ │
│ │ + Criterios │ │ (Jules Agent Run) │ │ Tests verdes │ │
│ └──────────────┘ └─────────────────────┘ └─────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘Ao transformar o fluxo em issue → tarefa de agente isolada → pull request, cada instância do Jules roda num contêiner efêmero e independente, nos datacenters do Google, e os agentes deixam de interferir uns nos outros.
Esse isolamento é o deste trecho: um branch e um pull request por agente. O Gestalt VFS, para que vários agentes editem o mesmo arquivo, veio depois. O artigo de fechamento conta essa parte.
O teto de 15 tarefas concorrentes
Esse número não existia em 11 de junho. Chegou em 6 de agosto de 2025, quando o Jules saiu da beta. No Google AI Pro a cota ficou em 15 tarefas concorrentes. O plano grátis ficou em 3. Desde então as ondas se armam contra esse teto: um agente fecha um marco delimitado, não um subsistema inteiro.
Nessa saída o Jules usava Gemini 2.5 Pro. Uma janela de mais de 1M de tokens alcançava um crate ou um módulo, com seus tipos e seus testes, se a issue não pretendesse ser o sistema completo.
3. Do caos ao arnês: GitCore e sprints de 30 minutos
Conforme o volume de PRs cresceu, apareceram anomalias: context drift, dependências cruzadas e branches órfãos. Não dava para depender da sorte.
Foi ali que desenvolvi o arnês de engenharia em volta do GitCore, transformando o processo num ciclo determinista de verificação formal:
- Matriz de features (
features.json): cada projeto define seu avanço percentual e critérios de aceitação verificáveis. - Limpeza automatizada de branches: reconciliação contínua dos branches remotos depois de cada merge.
- Baterias E2E e compilação estrita: nenhum PR é aprovado se não passar 100% da suíte de testes automatizados.
┌──────────────────────────────────────────────────────────────────┐
│ AI SPRINT LIFECYCLE (OLEADA DE 30 MINUTOS) │
├──────────────────────────────────────────────────────────────────┤
│ 1. Lectura de estado previo en Xavier (Memoria) y features.json │
│ 2. Fragmentación en 3-4 micro-issues por feature (Islas) │
│ 3. Auditoría pre-dispatch (0 colisiones de archivos) │
│ 4. Dispatch paralelo a Jules con label 'jules' (hasta 15 tasks) │
│ 5. Monitoreo asíncrono y resolución de suites de tests │
│ 6. Merge secuencial ordenado: Tipos ➔ Core ➔ API ➔ E2E │
│ 7. Actualización de métricas en features.json y cierre de sprint│
└──────────────────────────────────────────────────────────────────┘A conclusão foi imediata: organizar uma onda de agentes é exatamente planejar um sprint ágil de duas semanas, com a diferença de que o ciclo de estimativa, desenvolvimento, teste e entrega roda em 30 minutos.
4. Métricas no fechamento (28 de agosto de 2026)
As contagens de commits são um scan do workspace na data desta nota. Não são a recontagem desde 11 de junho, e as horas não saem do git log.
| Métrica do ecossistema | Valor |
|---|---|
| Primeiro push do Jules | 11 de junho de 2025, 02:05 UTC |
| Fechamento deste corte | 28 de agosto de 2026 (443 dias desde o primeiro push) |
| Repositórios no scan | 81 repositórios |
| Commits nesses repositórios | 11.240 commits |
| Commits de ondas (Jules e outros agentes) | 1.391 commits |
Features em features.json |
1.723 especificações |
| Pull requests mergeados | 1.000+ PRs |
| Horas equivalentes de trabalho manual | ~6.250 h, estimativa, fora do scan |
| Multiplicador | 6,5x – 8,0x, estimativa |
Repositórios públicos com mais atividade de agentes
A lista abaixo é só código público. Os totais da tabela misturam esse código com outro trabalho que não está publicado. Esse outro trabalho não tem nome, link nem contagem.
- Xavier: 1.922 commits no total / 255 commits do Jules (memória cognitiva vetorial em Rust).
- OrionHealth: 1.243 commits no total / 61 commits do Jules (saúde offline-first em Flutter).
- WorldExams: 844 commits no total / 85 commits do Jules (prática de exames, offline-first).
- Gestalt: 635 commits no total / 200 commits do Jules (orquestrador multiagente em Rust).
O inventário local-first está em Shelf.
5. Padrões-chave: microfragmentação e ilhas de arquivos disjuntas
Para que 15 agentes concorrentes trabalhem sem se destruir, o arnês implementa duas regras que não cedem:
A. Microfragmentação
Nenhuma issue passa de 150 linhas de impacto nem cobre mais de duas camadas de arquitetura. Cada feature grande se divide em:
[Micro-A]: contratos de tipos, traits e structs.[Micro-B]: lógica pura de domínio e algoritmos.[Micro-C]: adaptadores de entrada/saída (HTTP, IPC, CLI).[Micro-D]: suítes de testes unitários e mocks.
B. Ilhas de arquivos disjuntas
Antes de despachar uma onda com o label jules, um script valida que a interseção dos arquivos atribuídos a cada issue é um conjunto vazio:
# Verificación de Islas de Archivos Disjuntas (Pre-Dispatch QA)
islands = {
'#issue-101': ['crates/core/src/types.rs'],
'#issue-102': ['crates/core/src/codec.rs'],
'#issue-103': ['crates/api/src/routes.rs'],
'#issue-104': ['crates/core/tests/e2e_test.rs'],
}
for i1, f1 in islands.items():
for i2, f2 in islands.items():
if i1 < i2 and set(f1) & set(f2):
raise SystemExit(f"❌ COLISIÓN DETECTADA: {i1} y {i2} tocan {set(f1) & set(f2)}")
print("✅ 100% Islas Disjuntas Verificadas.")6. A tríade de infraestrutura: GitCore, Hermes e Xavier
O Jules não opera no vazio. A articulação de todo o ecossistema depende de três pilares feitos para isso:
┌──────────────────────────────┐
│ XAVIER (Memoria Viva) │
│ Contexto histórico & Vector │
└──────────────┬───────────────┘
│ Context Feed
▼
┌──────────────────┐ ┌──────────────┐ ┌──────────────────┐
│ HERMES GATEWAY │ ───► │ GITCORE CLI │ ───► │ GOOGLE JULES │
│ Despacho Rápido │ │ State Engine │ │ 15 Parallel PRs │
└──────────────────┘ └──────────────┘ └──────────────────┘- GitCore: o arnês mestre. Governa o contrato 1 issue → 1 branch → 1 PR, atualiza
features.jsone roda os linters antes do merge. - Hermes: o dispatcher. Gere o ciclo de vida dos agentes e os tetos de cota.
- Xavier: memória cognitiva persistente com busca semântica vetorial. Alimenta as issues com decisões de arquitetura tomadas meses antes.
7. O que ainda aperta
Desde o primeiro push, em 11 de junho de 2025, o fluxo está sendo apertado em 4 pontos:
- Asserção semântica no CI: validar a compatibilidade de tipos entre branches da mesma onda antes do merge em
main. - Alertas precoces de timeout: prever quando um agente passa de 15 minutos numa compilação pesada.
- Ingestão em tempo real no Xavier: webhooks que indexam o diff de cada PR aprovado na memória vetorial.
- Sandbox efêmero de rede: isolamento de sockets e portas para suítes de testes concorrentes.
8. Conclusão: a nova era da engenharia
A lição dura deste primeiro ano: o salto real de produtividade não é escrever código mais rápido com um autocompletar. É desenhar arneses rigorosos que articulem enxames autônomos em paralelo.
O Google Jules, apoiado pelo Gemini e orquestrado por um arnês determinista como o GitCore, mostrou que um só engenheiro, com a arquitetura certa, pode liderar e entregar projetos com a cadência, a robustez e a qualidade de um time de engenharia completo.
Continua a leitura
As ondas de 15 issues paralelas citadas neste post (Wave 1, Wave 2, Wave 3) já têm um artigo próprio: Waves: ondas como sprints de 30 minutos e Gestalt VFS. Ali explico por que 30 min × N ondas vencem o sprint clássico, e apresento o Gestalt VFS como a prova de conceito que rompe o teto de paralelismo (vários agentes no mesmo arquivo, merge em Rust).
11 июня 2025, в 02:05 UTC, Jules сделал первый push в моём аккаунте. Pull request смержили в 03:50 UTC того же дня. Jules был в публичной бете с Google I/O 20 мая. Первое изменение с фичей пришло через 22 минуты, в том же pull request.
К 28 августа 2026, когда в 81 репозитории насчитали 11 240 коммитов, поток уже не чат. Это асинхронная детерминированная фабрика софта, которая отправляет волны до 15 параллельных микрозадач в Google Jules. Их координирует Hermes, а проверяет конечный автомат GitCore.
Это техническая ретроспектива того отрезка: как менялись инструменты, как обходились столкновения контекста, метрики на закрытии и что из этого осталось.
1. Начало: минималистская позиция и первые инструменты
К июню 2025 я уже пробовал локальных агентов для кода. Разрез — тот первый push Jules, а не IDE. Google Antigravity ещё не было: он вышел 18 ноября 2025, в один день с Gemini 3, как IDE с агентами. Волны в этой заметке отправляет Jules.
Техническая позиция по-прежнему минималистская:
Принцип минимального трения: Чем меньше инструментов, расширений и промежуточных настроек ты копишь, тем ты продуктивнее. Меньше времени на споры, каким редактором пользоваться, больше — на задачу.
Той весной у Google Labs были две разные вещи. Jules — асинхронный агент: клонирует репозиторий в VM и возвращает pull request. Публичная бета шла с 20 мая по 6 августа 2025. Google Stitch генерирует интерфейс, а не патчи к репозиторию. Он вышел в тот же день, 20 мая.
Мы понимали, что работаем как early adopters («подопытные») на технологии, которая только рождалась. Ставка на дне тоже была ясной: Google не делал ещё одно локальное автодополнение. Он ставил самое большое облако планеты под разработку софта.
2. Узкое место: GitHub как шина вычислений
Любой инженер, который отдавал работу 4 или 5 агентам на одной локальной машине, упирается в ту же физическую стену: столкновения файлов и затёртое состояние. Два агента, правящие один файл локально, уничтожают рабочее дерево.
На том отрезке выход был не виртуальной файловой системой. Это был пайплайн, который индустрия уже решила: GitHub.
┌────────────────────────────────────────────────────────────────────────┐
│ PIPELINE DISTRIBUIDO DE GOOGLE JULES │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ GitHub Issues Google Cloud Compute Pull Requests │
│ ┌──────────────┐ ┌─────────────────────┐ ┌─────────────────┐ │
│ │ Spec atómico │ ────► │ Sandbox Aislado │ ──►│ Diff limpio + │ │
│ │ + Criterios │ │ (Jules Agent Run) │ │ Tests verdes │ │
│ └──────────────┘ └─────────────────────┘ └─────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘Когда поток стал issue → изолированная задача агента → pull request, каждый экземпляр Jules работает в своём эфемерном контейнере в датацентрах Google, и агенты больше не мешают друг другу.
Такая изоляция — про этот отрезок: одна ветка и один pull request на агента. Gestalt VFS, чтобы несколько агентов правили один файл, появился позже. Закрывающая статья рассказывает ту часть.
Потолок в 15 одновременных задач
Этого числа 11 июня не было. Оно пришло 6 августа 2025, когда Jules вышел из беты. На Google AI Pro квота стала 15 одновременных задач. Бесплатный план остался на 3. С тех пор волны собирают под этот потолок: один агент закрывает ограниченную веху, а не целую подсистему.
На том выпуске Jules использовал Gemini 2.5 Pro. Окна больше чем в 1M токенов хватало на crate или модуль, с его типами и тестами, если issue не притворялся всей системой.
3. От хаоса к упряжи: GitCore и спринты по 30 минут
Когда PR стало больше, полезли аномалии: context drift, перекрёстные зависимости и осиротевшие ветки. На удачу опираться было нельзя.
Тогда я собрал инженерную упряжь вокруг GitCore и превратил процесс в детерминированный цикл формальной проверки:
- Матрица фич (
features.json): каждый проект задаёт процент готовности и проверяемые критерии приёмки. - Автоочистка веток: непрерывное согласование удалённых веток после каждого merge.
- Наборы E2E и строгая сборка: PR не одобряют, если он не проходит 100% автоматических тестов.
┌──────────────────────────────────────────────────────────────────┐
│ AI SPRINT LIFECYCLE (OLEADA DE 30 MINUTOS) │
├──────────────────────────────────────────────────────────────────┤
│ 1. Lectura de estado previo en Xavier (Memoria) y features.json │
│ 2. Fragmentación en 3-4 micro-issues por feature (Islas) │
│ 3. Auditoría pre-dispatch (0 colisiones de archivos) │
│ 4. Dispatch paralelo a Jules con label 'jules' (hasta 15 tasks) │
│ 5. Monitoreo asíncrono y resolución de suites de tests │
│ 6. Merge secuencial ordenado: Tipos ➔ Core ➔ API ➔ E2E │
│ 7. Actualización de métricas en features.json y cierre de sprint│
└──────────────────────────────────────────────────────────────────┘Вывод был сразу: собрать волну агентов — то же самое, что спланировать двухнедельный agile-спринт, только цикл оценки, разработки, теста и сдачи укладывается в 30 минут.
4. Метрики на закрытии (28 августа 2026)
Счётчики коммитов — это скан рабочего пространства на дату заметки. Это не пересчёт с 11 июня, и часы не берутся из git log.
| Метрика экосистемы | Значение |
|---|---|
| Первый push Jules | 11 июня 2025, 02:05 UTC |
| Закрытие этого среза | 28 августа 2026 (443 дня с первого push) |
| Репозитории в скане | 81 репозиторий |
| Коммиты в этих репозиториях | 11 240 коммитов |
| Коммиты волн (Jules и другие агенты) | 1 391 коммит |
Фичи в features.json |
1 723 спецификации |
| Смерженные pull request | 1 000+ PR |
| Эквивалент ручной работы | ~6 250 ч, оценка, вне скана |
| Множитель | 6,5x – 8,0x, оценка |
Публичные репозитории с самой большой агентной активностью
Список ниже — только публичный код. Итоги таблицы смешивают этот код с другой работой, которая не опубликована. У той работы нет имени, ссылки и отдельного счёта.
- Xavier: 1 922 коммита всего / 255 коммитов Jules (векторная когнитивная память на Rust).
- OrionHealth: 1 243 коммита всего / 61 коммит Jules (offline-first здоровье на Flutter).
- WorldExams: 844 коммита всего / 85 коммитов Jules (практика экзаменов, offline-first).
- Gestalt: 635 коммитов всего / 200 коммитов Jules (мультиагентный оркестратор на Rust).
Локальный инвентарь — на Shelf.
5. Ключевые приёмы: микрофрагментация и непересекающиеся файловые острова
Чтобы 15 одновременных агентов работали и не уничтожали друг друга, упряжь держит два правила, которые не гнутся:
A. Микрофрагментация
Ни одна issue не превышает 150 строк воздействия и не покрывает больше двух архитектурных слоёв. Каждую большую фичу режут на:
[Micro-A]: контракты типов, трейты и структуры.[Micro-B]: чистая доменная логика и алгоритмы.[Micro-C]: адаптеры ввода/вывода (HTTP, IPC, CLI).[Micro-D]: наборы юнит-тестов и моки.
B. Непересекающиеся файловые острова
Перед отправкой волны с меткой jules скрипт проверяет, что пересечение файлов, назначенных каждой issue, — пустое множество:
# Verificación de Islas de Archivos Disjuntas (Pre-Dispatch QA)
islands = {
'#issue-101': ['crates/core/src/types.rs'],
'#issue-102': ['crates/core/src/codec.rs'],
'#issue-103': ['crates/api/src/routes.rs'],
'#issue-104': ['crates/core/tests/e2e_test.rs'],
}
for i1, f1 in islands.items():
for i2, f2 in islands.items():
if i1 < i2 and set(f1) & set(f2):
raise SystemExit(f"❌ COLISIÓN DETECTADA: {i1} y {i2} tocan {set(f1) & set(f2)}")
print("✅ 100% Islas Disjuntas Verificadas.")6. Инфраструктурная триада: GitCore, Hermes и Xavier
Jules не работает в вакууме. Вся экосистема держится на трёх опорах, сделанных под это:
┌──────────────────────────────┐
│ XAVIER (Memoria Viva) │
│ Contexto histórico & Vector │
└──────────────┬───────────────┘
│ Context Feed
▼
┌──────────────────┐ ┌──────────────┐ ┌──────────────────┐
│ HERMES GATEWAY │ ───► │ GITCORE CLI │ ───► │ GOOGLE JULES │
│ Despacho Rápido │ │ State Engine │ │ 15 Parallel PRs │
└──────────────────┘ └──────────────┘ └──────────────────┘- GitCore: главная упряжь. Держит контракт 1 issue → 1 ветка → 1 PR, обновляет
features.jsonи гоняет линтеры до merge. - Hermes: диспетчер. Ведёт жизненный цикл агентов и потолки квоты.
- Xavier: постоянная когнитивная память с векторным семантическим поиском. Кормит issue архитектурными решениями, принятыми месяцы назад.
7. Что ещё подтянуть
С первого push, 11 июня 2025, поток подтягивают в 4 местах:
- Семантическая проверка в CI: совместимость типов между ветками одной волны до merge в
main. - Ранние предупреждения о таймауте: предсказать, что агент тратит больше 15 минут на тяжёлую сборку.
- Поток в Xavier в реальном времени: вебхуки, которые индексируют diff каждого одобренного PR в векторную память.
- Эфемерная сетевая песочница: изоляция сокетов и портов для параллельных тестовых наборов.
8. Вывод: новая эпоха инженерии
Жёсткий урок этого первого года: настоящий скачок производительности — не быстрее набирать код автодополнением. Это проектировать строгие упряжи, которые ведут автономные рои параллельно.
Google Jules, на силе Gemini и под детерминированной упряжью вроде GitCore, показал: один инженер с правильной архитектурой может вести и сдавать проекты с темпом, прочностью и качеством целой инженерной команды.
Читать дальше
Волны из 15 параллельных issue, о которых эта заметка (Wave 1, Wave 2, Wave 3), уже разобраны отдельно: Waves: волны как спринты по 30 минут и Gestalt VFS. Там я объясняю, почему 30 минут × N волн бьёт классический спринт, и показываю Gestalt VFS как проверку идеи, которая ломает потолок параллелизма (много агентов на одном файле, merge на Rust).
11 جون 2025، 02:05 UTC پر Jules نے میرے اکاؤنٹ میں پہلا push کیا۔ اسی دن 03:50 UTC پر pull request مرج ہوا۔ Jules 20 مئی کے Google I/O سے عوامی بی ٹا میں تھا۔ فیچر والی پہلی تبدیلی 22 منٹ بعد آئی، اسی pull request میں۔
28 اگست 2026 تک، 81 ریپوزٹریوں میں گنے 11,240 commits کے ساتھ، بہاؤ اب چیٹ نہیں رہا۔ یہ ایک غیر ہم وقت، متعین سافٹ ویئر فیکٹری ہے جو Google Jules کو زیادہ سے زیادہ 15 متوازی خرد کاموں کی لہریں بھیجتی ہے۔ ہم آہنگی Hermes کرتا ہے، اور جانچ GitCore کی اسٹیٹ مشین کرتی ہے۔
یہ اس مدت کا فنی جائزہ ہے: اوزار کیسے بدلے، سیاق کی ٹکر کیسے ٹالی گئی، اختتام کے اعداد، اور کیا سیکھا۔
1. آغاز: کم سے کم رُخ اور پہلے اوزار
جون 2025 تک میں مقامی کوڈنگ ایجنٹ آزما چکا تھا۔ کٹاؤ Jules کے اس پہلے push پر ہوا، کسی IDE پر نہیں۔ Google Antigravity تب تھا ہی نہیں: وہ 18 نومبر 2025 کو آیا، Gemini 3 کے اسی دن، ایجنٹوں والا IDE بن کر۔ اس نوٹ کی لہریں Jules بھیجتا ہے۔
فنی رُخ اب بھی کم سے کم ہے:
کم سے کم رگڑ کا اصول: جتنے کم اوزار، ایکسٹینشن اور درمیانی سیٹنگیں جمع کرو گے، اتنے زیادہ پیداوار والے رہو گے۔ کون سا ایڈیٹر، اس بحث میں کم وقت، اور مسئلے پر زیادہ وقت۔
اس موسم بہار Google Labs کے پاس دو الگ چیزیں تھیں۔ Jules غیر ہم وقت ایجنٹ ہے: VM میں ریپو کلون کرتا ہے اور pull request لوٹاتا ہے۔ عوامی بی ٹا 20 مئی سے 6 اگست 2025 تک رہا۔ Google Stitch انٹرفیس بناتا ہے، ریپوزٹری کا پیچ نہیں۔ وہ بھی اسی 20 مئی کو آیا۔
ہمیں معلوم تھا کہ ہم ایک نئی تکنیک پر early adopters (“تجربے کے موضوع”) کی طرح کام کر رہے تھے۔ نیچے کی شرط بھی صاف تھی: Google ایک اور مقامی کوڈ-autocomplete نہیں بنا رہا تھا۔ وہ سیارے کے سب سے بڑے کلاؤڈ کو سافٹ ویئر کی تعمیر کے نیچے رکھ رہا تھا۔
2. رکاوٹ: حساب کی بس کے طور پر GitHub
جس انجینئر نے ایک ہی مقامی مشین پر 4 یا 5 ایجنٹ اکٹھے چلا کر کام سونپا ہے، وہ اسی طبعی دیوار سے ٹکراتا ہے: فائل کا ٹکراؤ اور حالت کا مٹ جانا۔ دو ایجنٹ مقامی طور پر ایک ہی فائل میں ترمیم کریں تو کام کی جگہ برباد ہو جاتی ہے۔
اس مدت میں راستہ ورچوئل فائل سسٹم نہیں تھا۔ وہ پائپ لائن تھی جسے صنعت پہلے ہی حل کر چکی تھی: GitHub۔
┌────────────────────────────────────────────────────────────────────────┐
│ PIPELINE DISTRIBUIDO DE GOOGLE JULES │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ GitHub Issues Google Cloud Compute Pull Requests │
│ ┌──────────────┐ ┌─────────────────────┐ ┌─────────────────┐ │
│ │ Spec atómico │ ────► │ Sandbox Aislado │ ──►│ Diff limpio + │ │
│ │ + Criterios │ │ (Jules Agent Run) │ │ Tests verdes │ │
│ └──────────────┘ └─────────────────────┘ └─────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘بہاؤ کو issue → الگ ایجنٹ کام → pull request بنانے پر، Jules کی ہر مثال Google کے ڈیٹا سینٹروں میں اپنے مختصر کنٹینر میں چلتی ہے۔ ایجنٹ ایک دوسرے سے نہیں ٹکراتے۔
یہ علیحدگی اسی مدت کی ہے: ایک ایجنٹ، ایک برانچ، ایک pull request۔ Gestalt VFS، تاکہ کئی ایجنٹ ایک ہی فائل میں ترمیم کر سکیں، بعد میں آیا۔ اختتامی مضمون وہ حصہ بتاتا ہے۔
15 ہم وقت کاموں کی چھت
یہ عدد 11 جون کو تھا ہی نہیں۔ وہ 6 اگست 2025 کو آیا، جب Jules بی ٹا سے باہر نکلا۔ Google AI Pro پر حد 15 ہم وقت کام ہوئی۔ مفت منصوبہ 3 پر رہا۔ تب سے لہریں اسی چھت کے خلاف بنتی ہیں: ایک ایجنٹ ایک محدود سنگِ میل بند کرتا ہے، پورا ذیلی نظام نہیں۔
اس اجرا میں Jules Gemini 2.5 Pro استعمال کرتا تھا۔ 1M سے زیادہ ٹوکن کی کھڑکی ایک crate یا ایک ماڈیول کے لیے کافی تھی، اس کی اقسام اور ٹیسٹوں سمیت، اگر issue پورے نظام ہونے کا دعویٰ نہ کرے۔
3. انتشار سے ہارنس تک: GitCore اور 30 منٹ کے اسپرنٹ
PR بڑھے تو بے قاعدگیاں آئیں: context drift، کٹی انحصاریاں، اور یتیم برانچیں۔ قسمت پر انحصار نہیں رہ سکتا تھا۔
تب میں نے GitCore کے گرد انجینئرنگ ہارنس بنایا، اور عمل کو رسمی جانچ کا متعین چکر بنا دیا:
- فیچر میٹرکس (
features.json): ہر منصوبہ اپنی پیش رفت کا فیصد اور جانچے جا سکنے والے قبولیت کے معیار طے کرتا ہے۔ - برانچ کی خودکار صفائی: ہر مرج کے بعد دور دراز برانچوں کا مسلسل میل۔
- E2E سوٹ اور سخت بلڈ: خودکار ٹیسٹ سوٹ کا 100% پاس ہوئے بغیر کوئی PR منظور نہیں ہوتا۔
┌──────────────────────────────────────────────────────────────────┐
│ AI SPRINT LIFECYCLE (OLEADA DE 30 MINUTOS) │
├──────────────────────────────────────────────────────────────────┤
│ 1. Lectura de estado previo en Xavier (Memoria) y features.json │
│ 2. Fragmentación en 3-4 micro-issues por feature (Islas) │
│ 3. Auditoría pre-dispatch (0 colisiones de archivos) │
│ 4. Dispatch paralelo a Jules con label 'jules' (hasta 15 tasks) │
│ 5. Monitoreo asíncrono y resolución de suites de tests │
│ 6. Merge secuencial ordenado: Tipos ➔ Core ➔ API ➔ E2E │
│ 7. Actualización de métricas en features.json y cierre de sprint│
└──────────────────────────────────────────────────────────────────┘نتیجہ فوراً آیا: ایجنٹوں کی لہر منظم کرنا ٹھیک دو ہفتے کے ایجائل اسپرنٹ کی منصوبہ بندی جیسا ہے، فرق یہ ہے کہ اندازہ، تعمیر، ٹیسٹ اور سپردگی کا چکر 30 منٹ میں چلتا ہے۔
4. اختتام کے اعداد (28 اگست 2026)
commit کی گنتی اس نوٹ کی تاریخ پر کام کی جگہ کا اسکین ہے۔ یہ 11 جون سے دوبارہ گنتی نہیں، اور گھنٹے git log سے نہیں آتے۔
| ماحولیاتی پیمانہ | قدر |
|---|---|
| Jules کا پہلا push | 11 جون 2025، 02:05 UTC |
| اس کٹاؤ کا اختتام | 28 اگست 2026 (پہلے push سے 443 دن) |
| اسکین میں ریپوزٹریاں | 81 ریپوزٹریاں |
| ان ریپوزٹریوں میں commits | 11,240 commits |
| لہروں کے commits (Jules اور دوسرے ایجنٹ) | 1,391 commits |
features.json میں فیچر |
1,723 تصریحیں |
| مرج شدہ pull request | 1,000+ PR |
| دستی کام کے مساوی گھنٹے | ~6,250 گھنٹے، تخمینہ، اسکین سے باہر |
| ضرب | 6.5x – 8.0x، تخمینہ |
سب سے زیادہ ایجنٹ سرگرمی والی عوامی ریپوزٹریاں
نیچے کی فہرست صرف عوامی کوڈ ہے۔ جدول کے مجموعے اس کوڈ کو ایسے کام سے ملاتے ہیں جو شائع نہیں۔ اس دوسرے کام کا نہ نام ہے، نہ لنک، نہ الگ گنتی۔
- Xavier: کل 1,922 commits / Jules کے 255 (Rust میں ویکٹر علمی میموری)۔
- OrionHealth: کل 1,243 commits / Jules کے 61 (Flutter میں آف لائن-پہلے صحت)۔
- WorldExams: کل 844 commits / Jules کے 85 (امتحان کی مشق، آف لائن-پہلے)۔
- Gestalt: کل 635 commits / Jules کے 200 (Rust میں کثیر-ایجنٹ آرکیسٹریٹر)۔
لوکل-فرسٹ انوینٹری Shelf پر ہے۔
5. بنیادی نمونے: خرد تقسیم اور غیر متقاطع فائل جزیرے
15 ہم وقت ایجنٹ ایک دوسرے کو مٹائے بغیر کام کریں، اس کے لیے ہارنس دو قاعدے رکھتا ہے جو جھکتے نہیں:
A. خرد تقسیم
کوئی issue 150 سطروں کے اثر سے آگے نہیں جاتا، اور دو سے زیادہ تعمیراتی تہوں کو نہیں چھوتا۔ ہر بڑا فیچر بٹتا ہے:
[Micro-A]: قسم کے معاہدے، trait اور struct۔[Micro-B]: خالص ڈومین منطق اور الگورتھم۔[Micro-C]: ان پٹ/آؤٹ پٹ اڈاپٹر (HTTP، IPC، CLI)۔[Micro-D]: یونٹ ٹیسٹ سوٹ اور mock۔
B. غیر متقاطع فائل جزیرے
jules لیبل کے ساتھ لہر بھیجنے سے پہلے ایک اسکرپٹ جانچتا ہے کہ ہر issue کو دی گئی فائلوں کا تقاطع خالی مجموعہ ہے:
# Verificación de Islas de Archivos Disjuntas (Pre-Dispatch QA)
islands = {
'#issue-101': ['crates/core/src/types.rs'],
'#issue-102': ['crates/core/src/codec.rs'],
'#issue-103': ['crates/api/src/routes.rs'],
'#issue-104': ['crates/core/tests/e2e_test.rs'],
}
for i1, f1 in islands.items():
for i2, f2 in islands.items():
if i1 < i2 and set(f1) & set(f2):
raise SystemExit(f"❌ COLISIÓN DETECTADA: {i1} y {i2} tocan {set(f1) & set(f2)}")
print("✅ 100% Islas Disjuntas Verificadas.")6. بنیادی ڈھانچے کی تثلیث: GitCore، Hermes اور Xavier
Jules خالی جگہ میں نہیں چلتا۔ پورے ماحول کا جوڑ تین ستونوں پر ہے، جو اسی کے لیے بنے:
┌──────────────────────────────┐
│ XAVIER (Memoria Viva) │
│ Contexto histórico & Vector │
└──────────────┬───────────────┘
│ Context Feed
▼
┌──────────────────┐ ┌──────────────┐ ┌──────────────────┐
│ HERMES GATEWAY │ ───► │ GITCORE CLI │ ───► │ GOOGLE JULES │
│ Despacho Rápido │ │ State Engine │ │ 15 Parallel PRs │
└──────────────────┘ └──────────────┘ └──────────────────┘- GitCore: مرکزی ہارنس۔ یہ معاہدہ 1 issue → 1 برانچ → 1 PR چلاتا ہے،
features.jsonاپڈیٹ کرتا ہے، اور مرج سے پہلے linter چلاتا ہے۔ - Hermes: ڈسپیچر۔ یہ ایجنٹوں کا حیاتی چکر اور کوٹے کی حدیں سنبھالتا ہے۔
- Xavier: پائیدار علمی میموری، ویکٹر معنوی تلاش کے ساتھ۔ یہ issue کو مہینوں پہلے لیے گئے تعمیراتی فیصلوں سے بھرتا ہے۔
7. آگے کیا کسنا ہے
پہلے push، 11 جون 2025، کے بعد بہاؤ ان 4 جگہوں پر کسا جا رہا ہے:
- CI میں معنوی تصدیق: ایک ہی لہر کی برانچوں کے درمیان قسم کی مطابقت،
mainپر مرج سے پہلے۔ - ٹائم آؤٹ کی جلدی خبر: اندازہ کہ کوئی ایجنٹ بھاری تالیف پر 15 منٹ سے زیادہ لگائے گا۔
- Xavier میں حقیقی وقت کی انٹیک: webhook جو ہر منظور شدہ PR کے diff کو ویکٹر میموری میں فہرست کریں۔
- مختصر نیٹ ورک سینڈ باکس: ہم وقت ٹیسٹ سوٹ کے لیے ساکٹ اور پورٹ کی علیحدگی۔
8. نتیجہ: انجینئرنگ کا نیا دور
اس پہلے سال کا سیدھا سبق: پیداوار کی اصل چھلانگ autocomplete سے کوڈ تیزی سے ٹائپ کرنا نہیں ہے۔ یہ ایسے سخت ہارنس بنانا ہے جو خودمختار جھنڈ کو متوازی چلا سکیں۔
Google Jules، Gemini کی طاقت پر، اور GitCore جیسے متعین ہارنس سے چلتا ہوا، دکھاتا ہے کہ درست تعمیر والا ایک انجینئر پوری انجینئرنگ ٹیم کی لے، مضبوطی اور معیار کے ساتھ منصوبے لے جا سکتا ہے اور سونپ سکتا ہے۔
آگے پڑھیں
اس پوسٹ میں کہی 15 متوازی issue کی لہروں (Wave 1، Wave 2، Wave 3) کا الگ مضمون ہے: Waves: 30 منٹ کے اسپرنٹ کے طور پر لہریں اور Gestalt VFS۔ وہاں میں بتاتا ہوں کہ 30 منٹ × N لہریں کلاسک اسپرنٹ کو کیوں مات دیتی ہیں، اور Gestalt VFS کو اس ثبوت کے طور پر رکھتا ہوں جو متوازی پن کی چھت توڑتا ہے (ایک ہی فائل پر کئی ایجنٹ، Rust میں مرج)۔
2025 年 6 月 11 日 02:05 UTC，Jules 在我的账号上做了第一次 push。当天 03:50 UTC，那个 pull request 被合并。Jules 自 5 月 20 日的 Google I/O 起处于公开测试。带有功能的第一次改动在 22 分钟后到达，仍在同一个 pull request 里。
到 2026 年 8 月 28 日，81 个仓库里数出 11,240 个 commit。这条流水线不再是聊天：它是一座异步、确定性的软件工厂，向 Google Jules 派出最多 15 个并行微任务的波次，由 Hermes 协调，由 GitCore 的状态机核验。
这是那一段的技术回顾：工具怎么演进，怎么避开上下文碰撞，收口时的指标，以及我学到的东西。
1. 起点：极简立场和第一批工具
到 2025 年 6 月，我已经在本地试过编程代理。分界是 Jules 的那一次 push，不是某个 IDE。Google Antigravity 当时不存在：它在 2025 年 11 月 18 日发布，和 Gemini 3 同一天，是带代理的 IDE。这篇笔记里的波次由 Jules 派出。
我的技术立场仍然极简：
最小摩擦原则： 工具、扩展和中间配置堆得越少，你越有产出。少花时间争论用哪个编辑器，多花时间解决问题。
那个春天，Google Labs 有两件不同的东西。Jules 是异步代理：它在一台 VM 里克隆仓库，然后交回一个 pull request。公开测试从 5 月 20 日持续到 2025 年 8 月 6 日。Google Stitch 生成界面，不给仓库打补丁。它也在 5 月 20 日发布。
我们清楚自己是一门刚出生的技术上的 early adopters（“试验品”）。底层的判断也很清楚：Google 不是在做又一个本地代码补全，而是把这颗星球上最大的云放到软件开发下面。
2. 瓶颈：把 GitHub 当作计算总线
任何工程师如果让 4 或 5 个代理同时在同一台本地机器上干活，都会撞上同一堵物理墙：文件冲突和状态被覆盖。 两个代理在本地改同一个文件，工作区就毁了。
那一段的出路不是虚拟文件系统，而是业界已经解决的管道：GitHub。
┌────────────────────────────────────────────────────────────────────────┐
│ PIPELINE DISTRIBUIDO DE GOOGLE JULES │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ GitHub Issues Google Cloud Compute Pull Requests │
│ ┌──────────────┐ ┌─────────────────────┐ ┌─────────────────┐ │
│ │ Spec atómico │ ────► │ Sandbox Aislado │ ──►│ Diff limpio + │ │
│ │ + Criterios │ │ (Jules Agent Run) │ │ Tests verdes │ │
│ └──────────────┘ └─────────────────────┘ └─────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘把流程变成 Issue → 隔离的代理任务 → Pull Request 之后，每一个 Jules 实例都跑在 Google 数据中心里自己的短生命周期容器中，代理之间不再互相干扰。
这段时期的隔离就是这样：一个代理一条分支、一个 pull request。让多个代理编辑同一个文件的 Gestalt VFS 是后来的事。收口的那篇文章讲那一部分。
15 个并发任务的上限
6 月 11 日还没有这个数字。它出现在 2025 年 8 月 6 日，Jules 离开测试、正式发布的那天。Google AI Pro 的额度是 15 个并发任务。免费计划停在 3。从那时起，波次按这个上限来组：一个代理收掉一个有边界的里程碑，而不是整个子系统。
那次发布时，Jules 用的是 Gemini 2.5 Pro。超过 1M token 的窗口够一个 crate 或一个模块，连同它的类型和测试，前提是这个 issue 不假装自己是整个系统。
3. 从混乱到挽具：GitCore 和 30 分钟冲刺
PR 变多之后，异常出现了：context drift、交叉依赖，还有孤儿分支。不能靠运气。
那时我把工程挽具做在 GitCore 周围，把过程变成一个确定性的形式核验循环：
- 功能矩阵（
features.json）： 每个项目定义自己的进度百分比，以及可以核验的验收标准。 - 分支自动清理： 每次合并之后，持续核对远端分支。
- E2E 套件和严格编译： 自动化测试套件不是 100% 通过，PR 就不批准。
┌──────────────────────────────────────────────────────────────────┐
│ AI SPRINT LIFECYCLE (OLEADA DE 30 MINUTOS) │
├──────────────────────────────────────────────────────────────────┤
│ 1. Lectura de estado previo en Xavier (Memoria) y features.json │
│ 2. Fragmentación en 3-4 micro-issues por feature (Islas) │
│ 3. Auditoría pre-dispatch (0 colisiones de archivos) │
│ 4. Dispatch paralelo a Jules con label 'jules' (hasta 15 tasks) │
│ 5. Monitoreo asíncrono y resolución de suites de tests │
│ 6. Merge secuencial ordenado: Tipos ➔ Core ➔ API ➔ E2E │
│ 7. Actualización de métricas en features.json y cierre de sprint│
└──────────────────────────────────────────────────────────────────┘结论来得很快：组织一波代理，就等于计划一个两周的敏捷冲刺，差别是估算、开发、测试和交付这整个循环在 30 分钟里跑完。
4. 收口指标（2026 年 8 月 28 日）
commit 计数是这篇笔记日期上的一次工作区扫描。不是从 6 月 11 日重数的，小时数也不来自 git log。
| 生态指标 | 值 |
|---|---|
| Jules 的第一次 push | 2025 年 6 月 11 日，02:05 UTC |
| 这次收口 | 2026 年 8 月 28 日（距第一次 push 443 天） |
| 扫描中的仓库 | 81 个仓库 |
| 这些仓库中的 commit | 11,240 个 commit |
| 波次 commit（Jules 和其他代理） | 1,391 个 commit |
features.json 中的功能 |
1,723 条规格 |
| 已合并的 pull request | 1,000+ 个 PR |
| 等效的手工工时 | 约 6,250 小时，估算，不在扫描之内 |
| 乘数 | 6.5x – 8.0x，估算 |
代理活动最多的公开仓库
下面只列公开代码。表里的合计把这些代码和另一部分未发表的工作混在一起。那部分工作没有名字、没有链接、也没有单独计数。
- Xavier： 共 1,922 个 commit / Jules 255 个 (Rust 里的向量认知记忆)。
- OrionHealth： 共 1,243 个 commit / Jules 61 个 (Flutter 的离线优先健康应用)。
- WorldExams： 共 844 个 commit / Jules 85 个 (考试练习，离线优先)。
- Gestalt： 共 635 个 commit / Jules 200 个 (Rust 多代理编排器)。
本地优先的库存应用在 Shelf。
5. 关键模式：微切分和不相交的文件岛
要让 15 个并发代理干活而不互相毁掉，挽具有两条不让步的规则：
A. 微切分
没有一个 issue 的影响超过 150 行，也不跨过两层以上的架构。每个大功能拆成：
[Micro-A]：类型契约、trait 和 struct。[Micro-B]：纯领域逻辑和算法。[Micro-C]：输入/输出适配器（HTTP、IPC、CLI）。[Micro-D]：单元测试套件和 mock。
B. 不相交的文件岛
在用 jules 标签派出一波之前，一段脚本核验分配给每个 issue 的文件交集是空集：
# Verificación de Islas de Archivos Disjuntas (Pre-Dispatch QA)
islands = {
'#issue-101': ['crates/core/src/types.rs'],
'#issue-102': ['crates/core/src/codec.rs'],
'#issue-103': ['crates/api/src/routes.rs'],
'#issue-104': ['crates/core/tests/e2e_test.rs'],
}
for i1, f1 in islands.items():
for i2, f2 in islands.items():
if i1 < i2 and set(f1) & set(f2):
raise SystemExit(f"❌ COLISIÓN DETECTADA: {i1} y {i2} tocan {set(f1) & set(f2)}")
print("✅ 100% Islas Disjuntas Verificadas.")6. 基础设施三件套：GitCore、Hermes 和 Xavier
Jules 不是在真空里跑。整个生态靠三根为这件事做的柱子：
┌──────────────────────────────┐
│ XAVIER (Memoria Viva) │
│ Contexto histórico & Vector │
└──────────────┬───────────────┘
│ Context Feed
▼
┌──────────────────┐ ┌──────────────┐ ┌──────────────────┐
│ HERMES GATEWAY │ ───► │ GITCORE CLI │ ───► │ GOOGLE JULES │
│ Despacho Rápido │ │ State Engine │ │ 15 Parallel PRs │
└──────────────────┘ └──────────────┘ └──────────────────┘- GitCore： 主挽具。它管 1 个 Issue → 1 条分支 → 1 个 PR 这份契约，更新
features.json，并在合并前跑 linter。 - Hermes： 调度器。它管代理的生命周期和额度上限。
- Xavier： 持久的认知记忆，带向量语义搜索。它把几个月前的架构决定喂给 issue。
7. 接下来要收紧的地方
从 2025 年 6 月 11 日的第一次 push 起，流水线正在收紧的有 4 处：
- CI 里的语义断言： 同一波的分支在合并到
main之前，先核验类型是否相容。 - 超时的早期警报： 预测一个代理会不会在重编译上超过 15 分钟。
- 实时写入 Xavier： 用 webhook 把每个获批 PR 的 diff 索引进向量记忆。
- 短生命周期的网络沙箱： 为并发测试套件隔离 socket 和端口。
8. 结论：工程的新阶段
这一年真正的教训是：生产力的跳跃不是靠补全把代码打得更快，而是设计严格的挽具，让自主的群体并行运转。
Google Jules 靠 Gemini 撑着，又由 GitCore 这样的确定性挽具编排。它说明，一个工程师只要架构对，就可以用一支完整工程团队的节奏、稳固程度和质量来带领并交付项目。
继续读
这篇里提到的 15 个并行 issue 的波次（Wave 1、Wave 2、Wave 3）有一篇专门的文章：Waves：把波次当作 30 分钟冲刺，以及 Gestalt VFS。那里我解释为什么 30 分钟 × N 波胜过经典冲刺，并把 Gestalt VFS 作为打破并行上限的概念验证（多个代理改同一个文件，用 Rust 合并）。