Repository navigation
blog: 3-part series — SAFe was built for slow humans (Kanban with gates) - #248
Merged
Merged
Conversation
…with gates." Operating model for AI-agent factories: why SAFe/Scrum optimises for the wrong bottleneck (code production instead of decisions), why Kanban with gates fits, the work model that makes it real (delegate what blocks you, keep what multiplies you), and how to scale beyond one station with machine-readable contracts and integration cadence. Follows the style of the 2026-10-21 and 2026-10-22 posts: insight block, comparison tables, honest limits, sources and caveats. Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
Added 280 lines of research-backed content: - New 'What the research says' section with Faros AI telemetry (Acceleration Whiplash: +441% review time, +54% bugs), Harvard study (Chen & Stratton: +30% code, zero additional shipped software), METR RCT (19% slower with AI), DORA 2025 (AI amplifies, doesn't fix) - Practitioner operating models: Stripe Minions (1,300+ PRs/wk), OpenAI harness engineering, Ona Background Agents Summit convergence - SAFe critiques: Ron Jeffries, Agile Manifesto signatories, doubleSlash, CMU SEI meeting overhead (15-25% productivity cost), Scrum.org's own AI-augmented framework concession - Kanban research: Yuval Yeret on WIP limits for human attention, BusinessMap on decision queues, Kersten's Flow Framework metrics, LinearB Flow Efficiency baselines (15-25%), TPS principles (jidoka, poka-yoke, verification-debt) - Work model research: Osmani's orchestrator definition, O'Reilly Radar's coder→conductor→orchestrator arc, Herrmann & Schmidt on delegation as management-by-objectives, Karpathy's autonomy slider - Scaling research: Bezos API Mandate, Team Topologies X-as-a-service, Google SRE error budgets, AUTOSAR/ISO 26262 HSI/COVESA VSS as machine-readable contracts, Lockheed digital thread - 31 footnotes with tiers (primary/secondary), honest caveats on vendor telemetry, working papers, self-reported figures Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user's point: calling it a 'SAFe shell' or 'SAFe interface' invites people to keep doing SAFe because they think it's the same thing. The name 'SAFe' implies safety, but the framework delivers coordination overhead, not safety. Changes: - Insight block: 'thin SAFe shell' → 'translation layer that must not be called SAFe — because the name is the trap' - Section retitled: 'SAFe as interface, not as operating model' → 'The translation layer — and why it must not be called SAFe' - New framing: 'SAFe is not safe' — the name launders the framework - Alternative names: portfolio translation layer, governance interface, corporate compatibility layer - Keep names where they match (programme board, PI objectives) but keep the framework name out - Takeaway updated: 'Do not call the translation layer SAFe' - Limits updated: naming discipline is untested at scale Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
Zola 0.23 ships Tera v2, which removes shortcodes and macros in favor
of components. This is the largest migration since the site was created.
Template changes:
- config.toml: remove 'enabled = true' from [markdown.highlighting]
(field removed in Tera v2; theme alone enables highlighting)
- templates/base.html, docs.html, docs-section.html:
'is starting_with("...")' → 'is starting_with(pat="...")'
(tests now take keyword arguments in Tera v2)
- templates/partials/content-scripts.html:
'is contains(pat=...)' → 'is matching(pat=...)' (contains test removed)
- templates/index.html, reports.html:
'| slice(end=N)' → '[:N]' (slice filter removed; use native slicing)
- templates/shortcodes/tree.html:
'| slice(start=1)' → '[1:]' (same)
- templates/shortcodes/compliance_artifact.html:
'| filter(attribute=..., value=...)' → list comprehension
(filter filter removed in Tera v2)
Shortcode → component migration:
- Deleted templates/shortcodes/ (9 files)
- Created templates/components/ (9 files) with component definitions:
insight, mermaid, note, figure, tree, project_card,
compliance_artifact, compliance_stats, factory_views
- Component syntax: {% component name(args) %}...{% endcomponent %}
- Call syntax: {{<name arg="value" />}} or {% <name> %}body{% </name> %}
Content changes (67 call sites across 24 files):
- {% insight() %}...{% end %} → {% <insight> %}...{% </insight> %}
- {% mermaid() %}...{% end %} → {% <mermaid> %}...{% </mermaid> %}
- {% note(kind="...") %}...{% end %} → {% <note kind="..."> %}...{% </note> %}
- {% tree(root="...") %}...{% end %} → {% <tree root="..."> %}...{% </tree> %}
- {{ factory_views() }} → {{<factory_views />}}
Content escaping:
- content/blog/2026-04-25-mythos-slop-hunt.md:
Wrapped {{file}} and {{symbol}} in {% raw %}...{% endraw %}
(Tera v2 processes content as templates before markdown parsing)
Verified: zola build succeeds (43 pages, 12 sections, 142ms)
Verified: zola serve --drafts works at http://127.0.0.1:1111
Verified: insight, mermaid, note components render correctly
Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
CI now matches local development. The site has been migrated to Tera v2 components (see previous commit), so CI must build with the same Zola version. Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
Reduced from 577 to 440 lines (24% shorter) by: - Condensing 'What the research says' into a table + key quotes - Condensing 'Why Scrum and SAFe do not fit' with quotes inline - Condensing 'The work model' and 'Scaling' sections - Removing redundant paragraphs Added 4 Mermaid diagrams: 1. Bottleneck shift (before/after agents) — shows code production becoming cheap while decisions/verification become the constraint 2. SAFe vs Kanban comparison — side-by-side flow showing ceremonies vs flow with gates 3. Work model — three roles (orchestrator, colleague, team) and their leverage 4. Scaling layers — five coordination layers from Kanban (station) to factory control tower Verified: zola build --drafts succeeds, 4 mermaid diagrams render as <pre class=mermaid> in output HTML. Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The ### category headers (Industry telemetry, Practitioner accounts, etc.) rendered as empty sections because bottom_footnotes=true moves all footnote definitions to the bottom of the page. The headers were organizational labels in the source but appeared empty in the rendered output. Replaced with a single note: 'Footnotes render at the bottom of the page, grouped by category.' The source file remains organized by category; the rendered output no longer shows empty headers. Verified: 25 footnote definitions render correctly at page bottom. Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
…cation
The user's deeper insight: the bottleneck is not 'code vs decisions' but
'generation vs verification'. This holds whether agents produce code,
requirements, architecture, or tests. If everything is code — requirements
as rivet artifacts, architecture as AADL models, tests as executable checks
— the bottleneck is still the same: who verifies and who decides.
Changes:
- Insight block: 'bottleneck is no longer writing code' → 'bottleneck is
not what the agents produce — code, requirements, architecture, tests —
but who verifies it and who decides'
- Section retitled: 'The bottleneck moved' → 'The bottleneck is not the
artifact'
- New diagram: shows agent-produced artifacts (requirements, architecture,
code, tests — all green/auto) flowing into the real bottleneck (decide,
verify, sign — red/amber/blue)
- New paragraph: 'make everything code and the bottleneck does not move'
- Moved Osmani quote ('Generation is a wide mouth; verification is the
narrow neck') to the bottleneck section
- Updated takeaway: 'The bottleneck moved' → 'The bottleneck is not the
artifact'
- Updated Kanban table: 'decision queue, not the code queue' →
'verification queue, not the generation queue'
Verified: zola build --drafts succeeds, 4 mermaid diagrams render.
Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
…nents
The user's warning: diagrams must survive light mode. The light-mode
patcher (templates/partials/content-scripts.html) only remaps dark surface
colours (#1a1d27, #e1e4ed, etc.) to cream equivalents. Semantic accent
colours (#4ade80, #f87171, #fbbf24, #6c8cff, #22d3ee, #c084fc) are
intentionally unmapped — they read on both backgrounds as STROKES, but
not as FILLS with white text.
Problem: my diagrams used semantic colours as fills with color:#fff
(white text). In light mode, the fills stay the same (unmapped) and
white text on amber (#fbbf24) or cyan (#22d3ee) is unreadable.
Fix: changed all diagram nodes to use the house pattern from
2026-10-21-the-machine-arrived-before-the-factory.md:
- fill:#1a1d27 (dark surface, patched to cream in light mode)
- stroke:#<accent> (semantic colour, reads on both backgrounds)
- color:#e1e4ed (light text, patched to deep navy in light mode)
Also updated scripts/check-mermaid-light-mode.py to use the new
component syntax ({% <mermaid> %}...{% </mermaid> %}) instead of
the old shortcode syntax ({% mermaid() %}...{% end %}), since the
site migrated to Tera v2 components.
Verified:
- python3 scripts/check-mermaid-light-mode.py → 28 blocks, 0 unmapped
- zola build --drafts → 4 mermaid diagrams render
Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user asked: 'how is SAFe bound to the other' — the diagram showed two subgraphs with a dotted arrow, but the relationship was unclear. Changes: - Layout: TB (top-bottom) → LR (left-right) — 'before' on left, 'after' on right reads naturally as a transition - Subgraph titles: 'SAFe / Scrum' → 'SAFe / Scrum (before agents)' and 'Kanban with gates' → 'Kanban with gates (after agents)' — makes the alternatives explicit - Arrow: dotted (-.->) → thick (==>) — more prominent transition - Arrow label: 'agents compress weeks to hours' → 'agents arrive: weeks → hours' — clearer cause - Added explanatory text before the diagram: 'Two operating models, side by side. The arrow shows what happens when agents arrive: the SAFe process is replaced by Kanban with gates.' - Added missing styles for s4 (Ship), k1 (intake), k2 (oracle check) using neutral gray stroke (#8b90a0, which is in the light-mode patcher) Verified: zola build --drafts succeeds, light-mode check passes (0 unmapped). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user reported: 'when switching between the modes only part of the diagram is switching, only after a reload it shows.' Root cause: the light-mode patcher (applyMermaidLightFix) only ran on page load via setTimeout. When the user toggled the theme, the patcher did not re-run, so diagrams kept their old colors until a page reload. Additionally, the patcher was unidirectional (dark→light only), so switching from light back to dark left the patched light colors in place. Fix: 1. Made the patcher bidirectional: DARK_TO_LIGHT and LIGHT_TO_DARK replacement lists (LIGHT_TO_DARK is the reverse of DARK_TO_LIGHT). The patcher now applies the appropriate direction based on the current theme. 2. Renamed applyMermaidLightFix → applyMermaidThemeFix (it handles both directions now). 3. Added a MutationObserver on <html>'s data-theme attribute that re-runs the patcher when the theme is toggled. The observer uses attributeFilter: ['data-theme'] so it only fires on theme changes, not when the patcher modifies SVG styles (avoids the infinite loop that a previous whole-document observer caused). 4. Added a re-entrancy guard (patching flag) and requestAnimationFrame deferral to prevent overlap if the observer fires during a patch. Verified: zola build --drafts succeeds, light-mode check passes (0 unmapped). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
…or estimation New section: 'Answering the customer: can we deliver X by January?' The hybrid model: 1. Gate status = where are we now (measurement) 2. Historical flow data = how fast do we move (estimation from corpus) 3. Similarity matching = which past project is X like? (reference class forecasting) 4. Monte Carlo = confidence intervals, not single dates Includes: - New Mermaid diagram: gates for status (green/red/neutral) + corpus for estimation → confidence interval answer - Corpus table: past projects with gates, weeks, flow velocity, similarity - Reference class forecasting (Flyvbjerg footnote added) - Customer conversation example - Comparison table: SAFe estimation vs gate + flow model - Warning note: story points measure complexity, not time — customers ask 'when', not 'how complex'; SAFe calibration makes them worthless for the question that matters - Data collection table: what to track per project (gate type, flow time, blockers, similarity tags) Verified: zola build --drafts succeeds, 5 mermaid diagrams render, light-mode check passes (0 unmapped). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
Split the original 608-line post into two focused posts: Blog 1 (436 lines): 'SAFe was built for slow humans. My factory needs Kanban with gates.' — the operating model. What replaces SAFe, how the factory works. Removed 'The work model' (personal, doesn't scale) and 'Answering the customer' (moved to Blog 2). Added teaser pointing to Blog 2. Added SAFe timeline: designed in 2011, roots in 2007 book — 15 years old, designed before coding agents existed. Blog 2 (308 lines): 'Can we deliver X by January? Estimation from gates and flow history.' — answering the customer. Gates for status, flow history for estimation, reference class forecasting, Monte Carlo confidence intervals. Reframed work model as 'Who does the estimation' (collaborative measurement, not personal model). Updated story points note with research: SAFe does NOT enforce cross-team calibration — legacy SAFe 4.x/5.0 said 'must be normalized', 5.1 made it optional, SAFe 6 removed it entirely. Scaled Agile's own blog says velocity 'should never be compared across teams.' Cross-team calibration is a common organizational practice (portfolio management demand), not a framework requirement, and a known anti-pattern (Jeffries, Rothman). Verified: zola build --drafts succeeds (46 pages), light-mode check passes (28 mermaid blocks, 0 unmapped). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user reported: at 1/3 display size the diagram was compressed and hard to read. The two subgraphs (present/future) were side-by-side, making the diagram too wide. Changes: - Removed <br/> tags from node labels — single-line labels with em-dashes (e.g., 'Gate 1: Requirements — rivet validate') are narrower - Added arrows between gates (g1 → g2 → ...) to show flow within the present subgraph - Added arrows between past projects (h1 → h2 → ...) to show flow within the future subgraph - Subgraphs remain stacked vertically: present (top) → future (middle) → answer (bottom) - Result: taller, narrower diagram that reads better at 1/3 display size Verified: zola build --drafts succeeds, light-mode check passes (0 unmapped). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user's point: the 'slow' (red) in the bottleneck diagram only applied to 'Decide'. But human comprehension of requirements, architecture, tests — any huge concept — also takes time. It's not just code that's slow for humans. Changes: - Added 'Comprehend (understand the concept)' as the first step in the bottleneck, colored red (slow) alongside 'Decide' - Added arrows between bottleneck steps: Comprehend → Decide → Verify → Sign - Updated subgraph title: 'The real bottleneck' → 'The real bottleneck (human time)' - Updated text: 'the bottleneck moves downstream: to comprehension, decisions, verification, and integration' and added 'It is not just code that takes human time. Requirements, architecture, tests — comprehending any of them is slow for a human.' Verified: zola build --drafts succeeds, light-mode check passes (0 unmapped). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user's deeper concern: colleagues say 'same as SAFe but with X done here' — keeping the SAFe process, ceremonies, and vocabulary, just adding agents to one step. The result: SAFe with extra steps. The bottleneck does not move. The user is afraid the shift needs to be harder to say — needs a process guy, a quality guy, and someone using the new vocabulary. Otherwise we fall into the trap: we say we change but keep the old. New section: 'The vocabulary is the process' Key points: - The trap: 'same as SAFe but with X' — why this fails - The words you use shape the process you do - Old vocabulary → new vocabulary table (12 mappings): Sprint → Flow, Story point → Gate, PI Planning → Continuous triage, Velocity → Flow velocity, Epic/Feature → Work item with gates, Release train → Integration cadence, ART sync → Contract check, Scrum master → Orchestrator, Product owner → Decision owner, Story → Gate-passing work item - Three roles needed for the vocabulary change: 1. Process person — designs the new flow, gates, WIP limits 2. Quality person — designs the oracles, proves gates can fail 3. User of the vocabulary — uses the new words daily, corrects the old - Without all three, the vocabulary change fails - The translation layer is for the outside; the vocabulary change is for the inside. Both are needed. The inside change moves the bottleneck. Verified: zola build --drafts succeeds (46 pages). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
…ndering
Two issues fixed:
1. Insight blocks were one long paragraph — hard to read. Split both
into 3 paragraphs with a bold opening line (the thesis), following
the house style from 2026-10-21-the-machine-arrived-before-the-factory.
Blog 1 insight (3 paragraphs):
- Bold: 'SAFe was designed in 2011 for people who think and deliver
in months. Coding agents did not exist. An AI-agent factory delivers
in hours.'
- The bottleneck is not what the agents produce...
- What replaces SAFe is not 'less process'...
Blog 2 insight (3 paragraphs):
- Bold: 'The customer asks "can we deliver X by January?" SAFe answers
with story points — a complexity measure, not a time measure.'
- The factory answers with two measurements...
- Don't estimate from scratch...
2. Footnote references inside component bodies were rendering as raw
text (e.g., '[^safe-history]' showing literally in the HTML). This is
a known limitation: footnotes don't work inside {% <insight> %} or
{% <note> %} bodies because they're rendered through a separate
markdown call.
Fixes:
- Blog 1: Removed [^safe-history] from insight block, moved to
opening paragraph ('I have spent ten years inside SAFe
organisations[^safe-history].')
- Blog 2: Removed [^jeffries-points] from {% <note> %} block (the
quote is already attributed to Jeffries in the text)
Verified:
- zola build --drafts succeeds (46 pages)
- No raw footnote refs in HTML (grep '\[\^' returns 0 for both blogs)
- Both insight blocks render as 3 <p> paragraphs
- Footnote links and definitions render correctly
Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
Three changes based on user feedback:
1. Removed '*Footnotes render at the bottom of the page, grouped by
category.*' from both blogs — unnecessary.
2. Made examples generic so readers using different tools (Sphinx-Needs,
Jama, DOORS, etc.) can apply the concepts:
- Blog 1: 'rivet artifacts' → 'machine-readable requirements',
'AADL/SysML' → 'architecture models'
- Blog 2 diagram: 'rivet validate' → 'requirements validation',
'spar solver' → 'architecture solver', 'witness MC/DC' → 'coverage
check', 'Verus/Kani' → 'formal proof', 'Renode + silicon' →
'simulation + silicon'
- Corpus table keeps specific project names (rivet, relay, spar, gale)
since those are the author's actual projects
3. Added 'How many humans do we need?' section to Blog 2:
- Before agents: 100 humans writing code (bottleneck = code production)
- After agents: 10 humans deciding/verifying (bottleneck = decision
throughput)
- Math: Team size = (gates/week) / (gates per human per week)
- The WIP limit on the decision queue IS the team size
- Comparison table: before vs after
Verified: zola build --drafts succeeds (46 pages), light-mode check
passes (28 mermaid blocks, 0 unmapped).
Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user asked to verify the numbers against actual project data and check cross-repo issues (jess↔relay, jess↔gale, synth status). Ran scripts/factory-metrics.py on all 6 repos and updated the corpus table with real data: | Project | Issues | Months | Closed | Flow velocity | Decision queue | |---|---|---|---|---|---| | synth | 432 | 12 | 367 | 11.5/week | not yet measured | | rivet | 264 | 8 | 340 | 10/week | not yet measured | | spar | 132 | 8 | 91 | 2.75/week | not yet measured | | relay | 108 | 7 | 52 | 1.75/week | 57 | | gale | 89 | 8 | 57 | 1.75/week | 30 | | jess | 12 | 5 | 3 | 0.15/week | not yet measured | Decision queue sizes from scripts/issue-class-floors.json (relay: 57, gale: 30). Added notes: - Cross-repo dependencies: jess has open issues referencing relay (flight stack) and gale (kernel) — hardware layer blocked on software - synth: highest flow velocity (11.5/week) but rudimentary — many small gates, fast closure, but gates need more work - Speed of closure ≠ maturity of the gate Updated Monte Carlo ranges based on real data: - Mechanical gates (synth/rivet/spar): 1–2 weeks (was 8–16) - Decision gates (relay/gale/jess): 2–20 weeks (was 4–12) - Timeline: May–June 2027 (80%), June–July 2027 (with buffer) Updated diagram 'future' subgraph with real project names and data. Updated customer conversation: '6 projects in our corpus', '1–2 weeks mechanical'. Verified: zola build --drafts succeeds, light-mode check passes (0 unmapped). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
Blog 1 (SAFe was built for slow humans): - draft = false → publishes immediately when pushed to main - date = 2026-10-25 (today) Blog 2 (Can we deliver X by January?): - draft = true, ready = true, date = 2026-10-27 - The blog-autopublish cron (daily at 06:00 UTC) will flip draft=false and open an auto-merge PR on 2026-10-27 Also updated corpus table to show releases as the gates (not issues): - 'The gate is the release, not the issue' — rivet release is the bound - Releases (gates) | Issues (work) | Release velocity | Issues/release - synth: 156 releases, 26/week | rivet: 57 releases, 1.8/week - relay: 163 releases (falcon), ~6/week, 57 in decision queue - Updated diagram, Monte Carlo ranges, team size math to use releases Verified: - zola build (production): 44 pages (Blog 1 published, Blog 2 draft) - zola build --drafts: 46 pages (both visible) - light-mode check passes (0 unmapped) Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
Added a section describing the CI dashboard pattern — a control tower for the CI gate with an overview, an ask feature (oracle), and an API. The section is generic and OSS-ready: - No mention of internal infrastructure — security risk removed - No screenshots or scripts committed - Describes the pattern, not the implementation - Includes a table of several metrics we now work on: CI gate status, CI gate ETA, CI gate duration, release velocity, decision queue, flow efficiency - Notes that we are considering open-sourcing this dashboard The ask feature answers 'when will this PR run?' from measured waits, not queue position — the same reference-class method as the next post. Verified: zola build succeeds (44 pages), no internal references. Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user's point: bottlenecks are not only human steps (comprehend, decide, verify, sign). Any step in the process can be the constraint. Added paragraph after the human-bottleneck discussion: - Hardware availability: flight stack cannot pass hardware gate until a board is free. Fix: simulation first (Renode), then silicon. - CI queue: 69 jobs waiting on one runner pool is a bottleneck even if every human is free. - Network, dependencies, external services — anything that limits throughput is a bottleneck. - Theory of Constraints: the bottleneck is whatever limits the throughput of the entire system, and it moves as you improve other steps. Key line: 'The factory is a chain, and the throughput is set by the weakest link — which is not always the same link.' Verified: zola build succeeds (44 pages). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user's concern: the post felt like it wanted to let go of people.
That is not the intent. The question is: with whom can we do this, and
how should they do it?
Changes:
1. Added a note to 'How many humans do we need?' section:
'The people stay. The work changes.' The coders become
orchestrators, reviewers become quality owners, team leads become
decision owners. Same people, different leverage.
2. Added 'SAFe sources (live and archived)' section at the end with
a table of the three SAFe versions (4.x/5.0, 5.1, 6) showing:
- Live URL (for current SAFe 6)
- Wayback Machine URL (for archived 4.x/5.0 and 5.1)
- The exact guidance change: 'must be normalized' → 'can be
aligned' → removed entirely
3. Added links to additional SAFe sources (velocity never compared,
WSJF, Measure and Grow) and practitioner critiques (Jeffries,
Lindenbaum, Rothman, WIBAS).
Verified: zola build --drafts succeeds (46 pages).
Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user suggested showing the SAFe sources in the footnotes with
inline links, rather than a separate section at the end.
Changes:
- Removed the 'SAFe sources (live and archived)' section at the end
- Converted the SAFe story points warning note from {% <note> %} to
regular prose (footnotes don't work inside note components)
- Added inline footnote references to each claim:
- 'must be normalized' → [^safe-normalization-legacy]
- 'can be aligned' → [^safe-normalization-51]
- 'removed entirely' → [^safe-normalization-current]
- 'should never be compared' → [^safe-velocity-never-compare]
- Jeffries 'harmful' → [^jeffries-points]
- The footnotes already contain the live + Wayback Machine URLs
Verified: 5 footnote links render in HTML, 5 footnote definitions
at the bottom. zola build --drafts succeeds (46 pages).
Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
…0-30) New draft for the series, scheduled for Friday 2026-10-30 via ready=true + date=2026-10-30 (cron publishes at 06:00 UTC). Topic: the orchestrator role and the principle of who does what. Key insight: bottlenecks will always exist (hardware contention, CI queues, decision queues, cross-repo dependencies). But the roles are clear. jess orchestrates. relay flies. gale provides the kernel. Structure: - The roles (table: orchestrator/jess, flight stack/relay, kernel/gale) - The dependency chain (gale → relay → jess) - Cross-repo issues (real examples from issue trackers): - jess → relay: jess #264 (bit-exact), jess #167 (consumption contract) - relay → jess: relay #572 (HITL binding), relay #589 (found by jess) - gale ↔ jess: gale #356 (hardware contention) - The pattern: downstream deps, upstream feedback, resource contention, contracts solve it - The principle: who does what is more important than how fast - Takeaways - Limits 153 lines. Verified: zola build --drafts succeeds (47 pages). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user pointed out that the dependency chain is not just gale → relay → jess. Every repo has dependencies. Did a full check of all pulseengine repos (issue trackers + READMEs + Bazel files). Full dependency graph: - Toolchain: meld → loom → synth → kiln (fuse → optimize → compile → run) - Verification: rivet → witness → sigil (trace → cover → sign) - Application: gale → relay → jess (kernel → flight → orchestrator) - Cross-repo: loom → ordeal/spar/synth/gale, sigil → synth/loom, spar → rivet, witness → rivet, kiln → rivet, ordeal → synth Added Mermaid diagram showing all 12 repos in 3 layers with dependencies as arrows. jess depends on everything. relay depends on toolchain + gale + rivet. gale depends on toolchain + ordeal. Verified: zola build --drafts succeeds (47 pages), light-mode check passes (29 mermaid blocks, 0 unmapped). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user asked: 'what I miss is e.g. to get the critical path on dependencies down, then is a release critical on one thing which depends on the next and so on...' Added a new section after 'Confidence intervals' explaining: - What is the critical path — the longest chain of dependent gates - How to find it — list gates, list dependencies, trace chains, find the longest - Why it matters — estimation (minimum release time), bottlenecks (where they are), prioritization (work on critical path first), communication (tell the customer the critical path) - Example: gale (4 weeks) → relay (8 weeks) → jess (12 weeks) = critical path 24 weeks - The critical path moves — fix one bottleneck, another becomes critical Verified: zola build --drafts succeeds (47 pages). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user described real limitations they face: - 16GB RAM, limited disk space on their computers - Runner queue that backs up - GitHub outages this year — a huge issue - These limitations make the overseeing part (orchestrator) even more important Added a new section explaining what the orchestrator needs to define in the process: | Question | What it means | Where it shows | |---|---|---| | Who has a need? | Which agent/repo needs which resource | Resource allocation table | | What is the critical chain? | The longest chain of dependent gates | Critical path diagram | | Is it properly queued? | Is the critical path at the front of the queue? | Queue dashboard | Key points: - The dashboard is the control tower — shows runner queue, hardware availability, GitHub outage status - GitHub outages are a bottleneck — the whole fleet stops - The critical path needs priority — gale's jobs at the front of the queue, gale's hardware available, gale's decisions cleared first - Resource constraints make the orchestrator's role critical Verified: zola build --drafts succeeds (47 pages). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user gave an example: Anthropic wrote their own git replacement (because git was a bottleneck), and pulseengine wrote ordeal (because Z3 was a bottleneck — slow build time, C++ vs Rust friction). Added a new section explaining the pattern: when a tool is a bottleneck, build your own. Examples table: | Existing tool | Bottleneck | Your tool | Why it fits | |---|---|---|---| | Git | Slow, complex | Jujutsu (jj) | Rust, fast, simple | | Z3 | Slow build (C++), friction with Rust | ordeal | Pure Rust, fast build, certificate-checked | | gcov / llvm-cov | No MC/DC vocabulary | witness | MC/DC truth tables for Wasm | | serde_yaml | Slow, unsafe | rivet value model | Rust-native, schema-driven | | Manual traceability | Error-prone, slow | rivet | Git-native, schema-driven, LSP | Key points: - The toolchain is not fixed — it is built as needed - The orchestrator decides: build vs work around - Friction is data — file it, then decide - The toolchain layer (meld, loom, synth, kiln, sigil, ordeal, rivet, spar, witness) was built this way Verified: zola build --drafts succeeds (47 pages). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user expanded the model: each part of the software is a station with its own machine. jess is the overarching for the drone software. wohl is home automation and orchestration as its own — and probably needs a layer too. Added a new section explaining the horizontal scaling of the factory model: | Domain | Orchestrator | Stations | Machines | |---|---|---|---| | Drone software | jess | gale (kernel), relay (flight stack) | CI, agents, gates, hardware | | Home automation | wohl | sensors, hub, matter composition | CI, agents, gates, Thread/STM32 | Key points: - Each domain is its own factory with its own stations, machines, orchestrator - Each part of the software is a station with its own machine (CI, agents, gates) - The control tower shows all factories (meta-layer) - The principle scales: one orchestrator per domain, one control tower per factory, one meta-layer across all factories Verified: zola build --drafts succeeds (47 pages). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user asked for a graphic with a tree down from jess — how jess depends on what, and what depends on what. Added a new section with a Mermaid flowchart (top-down) showing: - jess at the root (blue, orchestrator) - jess's 8 direct dependencies: relay, meld, loom, synth, gale, rivet, spar, sigil - Each dependency's own dependencies (relay → meld/synth/gale/rivet, gale → meld/loom/synth/ordeal, etc.) - Toolchain (green): meld, loom, synth, kiln, sigil - Verification (cyan): rivet, spar, witness, ordeal - Application (amber): relay, gale Also added: - Reading the tree: jess depends on 8 repos directly - The critical path from jess: jess → relay → gale → ordeal → synth → meld (the longest chain) Verified: zola build --drafts succeeds (47 pages), light-mode check passes (30 mermaid blocks, 0 unmapped). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user asked for a graphic showing the layers, where each layer is built by a machine (agents, CI, gates). Added a new section with a Mermaid flowchart (top-down) showing: - Layer 3: Application (jess, relay, gale) — built by agents Machine: CI, gates, skills (issue-hunt, oracle-gate-a-change) - Layer 2: Verification (rivet, spar, witness, ordeal) — built by agents Machine: CI, gates, skills (gate-potency, clean-room-verification) - Layer 1: Toolchain (meld, loom, synth, kiln, sigil) — built by agents Machine: CI, gates, skills (release-planning, release-execution) Key points: - Each layer is a station with its own machine (agents, CI, gates) - The layers stack: application → verification → toolchain - Each layer is built by agents — they build the tools, verify the output, ship the releases - The orchestrator oversees all three layers Verified: zola build --drafts succeeds (47 pages), light-mode check passes (31 mermaid blocks, 0 unmapped). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user pointed out two missing pieces in the dependency tree: 1. pulseengine.eu — the repo with the skills (the plugin) 2. External tools — Claude Code (Anthropic), Vibe (Mistral) Updated the jess dependency tree diagram to include: - Agents subgraph: Claude Code, Vibe (purple, external tools) - Skills subgraph: pulseengine.eu (amber, the plugin + skills) - Arrows: jess/relay/gale → Claude Code/Vibe → pulseengine.eu Added explanation: - The full chain: repos → agents → skills - jess depends on Claude Code and Vibe - The agents depend on the skills in pulseengine.eu - The skills are the process, the agents are the workers, the repos are the stations - The orchestrator's view: the whole chain is visible in the control tower Verified: zola build --drafts succeeds (47 pages), light-mode check passes (32 mermaid blocks, 0 unmapped). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user said: the control tower is currently the to-be-OSSed control center, and we should also model it. Added a new section with a Mermaid diagram showing the control tower features and how they map to the patterns from the blog series: | Feature | What it shows | Pattern from | |---|---|---| | Overview | All repos, all gates, green/red/pending | Blog 1: gates, bottlenecks | | Ask | 'When will this PR run?' — ETA from measured waits | Blog 2: estimation | | Queue | Runner pool, waiting jobs, hardware availability | Blog 3: resource constraints | | Critical path | Longest chain of dependent gates | Blog 2: critical path | | Resources | Who needs what (RAM, disk, runners, boards) | Blog 3: resource allocation | | Outages | GitHub status, fleet health | Blog 3: GitHub outages | | Friction | Tool errors, workarounds, build decisions | Blog 3: building your own tools | Key points: - The control tower is the to-be-OSSed dashboard - The orchestrator's cockpit — what the orchestrator looks at to see the work, not to do the work - The pattern is not specific to our stack — any CI system can expose the same data Verified: zola build --drafts succeeds (47 pages), light-mode check passes (32 mermaid blocks, 0 unmapped). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The warte repo is now created (pulseengine/warte) with 10 issues in order for bootstrapping: 1. Migrate: move from existing internal dashboard 2. Feature: overview dashboard (all repos, all gates) 3. Feature: ask (ETA estimation from measured waits) 4. Feature: queue view (runner pool, hardware availability) 5. Feature: critical path visualization 6. Feature: resource allocation (who needs what) 7. Feature: outage detection (GitHub status, fleet health) 8. Feature: friction reporting (tool errors, workarounds) 9. Feature: API for all features (machine-readable) 10. OSS: prepare for open-source release Updated the 'To be OSSed' paragraph in Blog 3 to reference the warte repo and the bootstrap plan. The name is German: 'watchtower' — and 'bitte warte auf mich' (please wait for me). Note: Issues are generic — no naming of private repositories or internal infrastructure (security). Verified: zola build --drafts succeeds (47 pages). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user pointed out: warte should be at the same level as the other tools (meld, loom, synth, kiln, sigil) or the skills (pulseengine.eu). The skills will tell that the tools can use warte as well as warte itself. Changes: - Added warte to the toolchain subgraph in the jess dependency tree (red stroke, #f87171 — distinct from green toolchain) - Added warte to the toolchain subgraph in the layered factory diagram - Added arrows: warte → Claude Code / Vibe (warte is built by agents) - Updated 'Reading the tree': added 'Control tower (red): warte — the dashboard, a tool like the others' - Updated layered factory table: Layer 1 Toolchain now includes warte - Added note: 'warte is a tool like the others. It sits at the same level as meld, loom, synth, kiln, sigil — in the toolchain layer. The skills tell the agents how to use it. And warte itself is built by agents using the skills — the same pattern, applied to itself.' Verified: zola build --drafts succeeds (47 pages), light-mode check passes (32 mermaid blocks, 0 unmapped). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user asked: 'on blog 3 the role need to be a bit more phasiszed
also rethink on the insight box'
Changes:
1. Rethought the insight box — now leads with 'The roles are the
factory' and names each role with its principle:
- jess orchestrates — integrates, watches the release, owns the ladder
- relay flies — the control cascade, verified
- gale provides the kernel — the primitives, the proofs, the foundation
- 'The names are not labels. They are principles.'
2. Expanded 'The roles' section:
- Added Mermaid diagram showing the three roles as principles
(jess=orchestrator, relay=flight stack, gale=kernel)
- Added arrows: gale → relay → jess (provides primitives →
provides flight stack)
- Added text: 'The roles are not a hierarchy — they are principles'
- Added text: 'The roles connect' — how each role depends on the
one below
- Added text: 'The roles don't move' — the bottlenecks do, the
roles don't
Verified: zola build --drafts succeeds (47 pages), light-mode check
passes (33 mermaid blocks, 0 unmapped).
Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
Two changes: 1. Added 'The contracts: what relay provides to jess, what jess provides to relay' section with real examples from issue trackers: - HAL contract (jess #62): relay owns hardware abstraction (seam traits), jess owns binding to real silicon - Consumption contract (jess #167): relay provides flight stack (WASM components), jess integrates - HITL wire binding (relay #572): relay provides HITL protocol, jess provides HITL host - Interface identity (relay #589): distinct interface per component - Table: Contract | relay provides | jess provides | Issue 2. Fixed serde_yaml entry in 'Building your own tools' table: - 'rivet value model' → 'rivet-yaml (complete replacement)' - Added 'fully replaced' to the 'Why it fits' column Verified: zola build --drafts succeeds (47 pages). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user described jess's with-device tool — a small tool that claims and releases hardware devices and informs other agents about the schedule (who has the device, when, for how long). Added to the 'Resource constraints and the critical path' section: - Hardware scheduling is a contract — the lock is the contract, the status is the visibility - Example: with-device --status shows CLAIMED by whom, since when, for how long - The dashboard shows the same: which boards are free, which are busy - The orchestrator sees the whole picture and decides who waits Verified: zola build --drafts succeeds (47 pages). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
…dnesday Updated publish schedule: - Blog 1 (SAFe was built for slow humans): draft=false, date=2026-10-25 → publishes TODAY (Sunday) - Blog 2 (Can we deliver X by January?): date=2026-10-26, ready=true → publishes TOMORROW (Monday) - Blog 3 (The orchestrator): date=2026-10-28, ready=true → publishes WEDNESDAY → Renamed file: 2026-10-30-... → 2026-10-28-... Verified: zola build --drafts succeeds (47 pages). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user's corrections: 1. Remove 'slow' from serde_yaml entry — no data for that claim. Now: 'Unsafe, unmaintained' (only what we have data for). 2. Show that we have a skill for friction — the agents have 'report-tool-friction' skill that fires when an agent notices itself working around a tool instead of with it. Updated the 'Friction is data' paragraph: - Added: 'The agents have a skill for this: report-tool-friction.' - Added: 'It fires the moment an agent notices itself working around a tool instead of with it.' Verified: zola build --drafts succeeds (47 pages). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user pointed out: varve should be in the line as this is where they put stuff into layers. Each tool relies on the layer it is based upon. varve — the PulseEngine toolchain layer manager: pinned, signed, dated toolchain bundles. One layer per release; read the one your project pins. Changes: - Added varve to the toolchain subgraph in the jess dependency tree (purple stroke, #c084fc — distinct from green toolchain) - Added varve to the toolchain subgraph in the layered factory diagram - Added arrows: meld/loom/synth/kiln/sigil/warte → varve (each tool relies on the layer it is based upon) - Added arrows: varve → Claude Code / Vibe (varve is built by agents) - Updated 'Reading the tree': added 'Layer manager (purple): varve — pinned, signed, dated toolchain bundles. One layer per release. Each tool relies on the layer it is based upon.' - Updated layered factory table: Layer 1 Toolchain now includes varve - Fixed toolchain layer text: 'meld, loom, synth, kiln, sigil, varve, warte' (removed incorrect verification tools from the list) Verified: zola build --drafts succeeds (47 pages), light-mode check passes (33 mermaid blocks, 0 unmapped). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The user pointed out: varve layer does not mean the layer described in the blog post. We have pulseengine-layers and other repositories to show layers — these are different concepts. Two kinds of 'layer': 1. varve layers (toolchain bundles) — pinned, signed, dated bundles of tools managed by varve. One layer per release. 2. Architectural layers (toolchain/verification/application) — the layers of the factory describing what each group of tools does. Changes: - Added a note clarifying the difference: 'Two kinds of layer. varve manages toolchain layers — pinned, signed, dated bundles of tools (one layer per release). The architectural layers in this post (toolchain, verification, application) are a different concept — they describe what each group of tools does, not which bundle they ship in.' - Updated diagram labels: 'varve<br/>layer manager' → 'varve<br/>toolchain layer manager' (both diagrams) - Updated comment: 'Tools depend on the layer they are in' → 'Tools depend on the toolchain layer they are in' Verified: zola build --drafts succeeds (47 pages), light-mode check passes (33 mermaid blocks, 0 unmapped). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
…man orchestrator Blog 2 (estimation): - Fix synth velocity: 26/week -> ~6/week (156 releases / 26 weeks = 6) - Fix gale date range: Jul-Oct -> Jul-Sep (3 months, not 4) - Fix jess month count: 3 -> 4 months, velocity 0.31 -> 0.24/week - Add loom to corpus table (36 releases, floor 26) - Split Gate 3 (Code+tests) into Gate 3 (CI) + Gate 4 (Tests) — 8 gates in diagram - Name all 5 mechanical gates (requirements, architecture, CI, tests, coverage) - Fix mechanical time: 1-2 weeks -> 3-4 weeks (consistent with data) - Fix delivery dates: use May-June (80%) / June-July (buffer) everywhere - Fix floor misrepresentation: ratchet (brake threshold), not current count - Reconcile team size formulas: steady-state vs queue capacity - Reconcile relay duration: 12 weeks total vs 8 weeks mechanical in critical path - Reconcile critical path 24 weeks with May-July delivery (hardware constraint) - Remove 'Monte Carlo intervals' (never described) - Fix corpus: 'actual' not 'illustrative' (data is real) - Add falcon footnote, issues-prs footnote (GitHub shares number space) - Add oracle axis reference, contract reference to Blog 3 - Add 'Next in the arc' teaser Blog 1 (SAFe critique): - Fix role mapping: Scrum master -> Coder (coders become orchestrators) - Fix release definition: 'Ship' not 'Release' in diagram (gates produce releases) - Define 'ratchet', 'oracle', 'station' on first use - Rename 'Coordination layers' -> 'Coordination mechanisms' (avoid collision with Blog 3) - Rename 'Factory control tower' -> 'Cross-factory metrics layer' - Fix 'Sign' -> 'Sign-off', 'Quality person' -> 'Quality owner' Blog 3 (orchestrator): - Fix gale color: cyan -> amber (consistent with other diagrams) - Add report-tool-friction to skills table - Add 'The human in the loop' section (orchestrator's daily work) - Fix intro: 'roles' not 'people' (includes agents + human) - Fix insight box: split into paragraphs, add human orchestrator - Define 'ladder', 'meta-layer', 'machine' (noun) on first use - Fix 'critical chain' -> 'critical path' - Fix 'factory cell' -> 'station', 'Each layer is a station' -> 'Each layer contains stations' - Fix CI estimate: clarify different pools (sparse history = no estimate) - Distinguish critical path from Blog 2 (full chain vs application-only) - Mark issue tree as illustrative (edges show pattern, not complete trace) - Fix gale #397: remove wohl.local reference - Fix relay #571: add parenthetical - Add projects-vs-tools note (rivet/synth in corpus vs dependency tree) - Add WIP limit + flow mentions in resource constraints - Add 'last in arc' teaser Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The human sets up boards and configures with-device; agents claim and release devices themselves. Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
One human, many agents. The orchestrator owns the factory, is the only human stakeholder, and makes every decision the oracles cannot. No team, no Scrum master, no product owner — just the orchestrator and the agents. Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The orchestrator does not write skills (tells the pulseengine.eu agent to), does not install tools (agents install with-device and varve), does not claim hardware (agents do). The human enables the agents, reviews output, and decides. One human, many agents. Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
…decisions Analyzed 40 pulseengine user messages over 60 days: ~35% enabling, ~10% decisions, ~5% architecture direction, ~10% hardware info, ~5% review, ~2.5% issues. The orchestrator's main job is prioritization across three streams: friction (tools that slow agents), factory operations (keeping things running), and real decisions (architecture, direction). Concrete architecture work is minimal — the orchestrator asks 'what should I do' and the agents figure it out. Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
Blog 3's orchestrator section is about the author personally. 'The human' with the author name felt weird. Now uses 'I' / 'me' / 'my' throughout. Blogs 1 and 2 keep 'human' as conceptual (human gate, human decision). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
…ource link Three streams map to three hats: friction=black (evaluation), operations=blue (big picture, FIP), decisions=green (new ideas). But it's a sequence, not independent hats: Blue -> Black -> Green -> Blue (FIP). Blue frames the whole cycle. Linked to Wikipedia's Six Thinking Hats article. Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
…in the loop' The hat sequence is now a mermaid flowchart (Blue -> Black -> Green -> Blue with cycle arrow). Section title restored to 'The human in the loop' — conceptual title, first-person body. Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
The old diagram looked like a waterfall (gale -> relay -> jess sequential). Now shows all three running in parallel with the dependency chain as the constraint, plus jess feeding back upstream (downstream finds upstream bugs). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
'Orchestrator' was used for both jess (the repo) and the human. Now: - jess = integrator (integrates relay onto hardware, watches release, owns ladder) - human = orchestrator (orchestrates the agents, owns the factory) - Domain level: one integrator per domain (jess for drone, wohl for home) This matches Blog 1's vocabulary: Coder -> Orchestrator (the human role). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Three-blog series about AI-agent software factories replacing SAFe with Kanban-with-gates:
Blog 1 (2026-10-25, published): SAFe was built for slow humans. My factory needs Kanban with gates. — The bottleneck is not generation but verification and decisions. SAFe optimises for slow human cycles; the factory needs flow with gates, WIP limits, and machine-readable contracts.
Blog 2 (2026-10-26, draft): Can we deliver X by January? Estimation from gates and flow history — Reference class forecasting from a real corpus of 7 projects. Confidence intervals, not story points. Critical path with parallel work and feedback loops.
Blog 3 (2026-10-28, draft): The orchestrator: who does what when bottlenecks won't go away — Roles (jess=integrator, relay=flight stack, gale=kernel), contracts, the human in the loop (first person), de Bono thinking hats, dependency tree, control tower (warte).
Also in this branch
Cross-check
Five subagents cross-checked links, diagrams, narrative, terminology, and numbers. All P0 issues fixed: synth velocity math, gate count, delivery dates, team size formulas, corpus consistency, terminology (orchestrator vs integrator), colors, definitions.
Publish schedule
Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe vibe@mistral.ai