diff --git a/ideas/time-estimates.org b/ideas/time-estimates.org index 14d6f00..da37da2 100644 --- a/ideas/time-estimates.org +++ b/ideas/time-estimates.org @@ -1,17 +1,68 @@ :PROPERTIES: :ID: dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70 +:CREATED: [2026-05-23 Sat] :END: #+title: Development Velocity and Timeline Estimates -#+filetags: :passepartout:economics:development:timeline:velocity: +#+filetags: :passepartout:economics:development:timeline:velocity:orders-of-magnitude: -At the observed velocity (initial TUI through to production readiness in a single session), the agent writes code and the symbolic engine verifies it at a cycle measured in minutes. The bottleneck is not coding speed — it is LLM API latency, ACL2 verification time, and human review of the 5% of edge cases Screamer flags. +The orders-of-magnitude time framework ([[file:orders-of-magnitude-time.org][Orders of Magnitude — Time]]) reveals that the original single-timeline estimate conflated two qualitatively different projects. The line counts are in plausible ranges for Lisp's density (~5-10× fewer lines than C++ for equivalent functionality), but the phases differ in their feedback regimes, constraints, and failure modes. The honest picture splits into two distinct phases. -**To neurosymbolic maturity (~4,500 lines):** ~80 cycles, 3-5 weeks, ~2-3 hours of human review. +**Old estimate:** 14,000 lines total, 3-6 months to replace the full computing stack. This was wrong because it treated all phases as linear — microcode has hardware latency (seconds per cycle), GUI has user-testing latency (days per iteration), and the browser alone is a years-scale project if done natively. The numbers don't add linearly across orders of magnitude. -**To [[file:self-driving-lisp-machine.org][self-driving Lisp Machine]] (Logos + Stoa hardware, +~6,000 lines):** ~60 cycles, 2-4 weeks. The microcode must be loaded onto physical hardware and benchmarked, adding seconds per cycle. +**Corrected estimate:** Two-phase approach with a clear middleground destination. -**Full Stoa (editor, browser, shell, Qt integration, ~3,500 lines):** ~30 cycles, 2-3 weeks. +--- -**Total from today to full Logos + Stoa + Agora triad:** 3-6 months. Most of that time is spent on design decisions and protocol specification, not on code. +## Phase Zero — The MVP (Linux-hosted, ships real product) -The system writes the code. The human makes architectural decisions and reviews the 5% ambiguous rules. This timeline assumes a rapid [[file:sufficiency-flip.org][sufficiency flip]] for each domain. See [[file:investment-thesis.org][Investment thesis]] for the business case that justifies this approach. +Run on Linux, use C libraries through CFFI, deliver value without replacing the OS. This is the [[file:sufficiency-flip.org][sufficiency flip]] applied to the verification layer only, not the whole stack. + +| Component | Lines | Method | Scale | +|---|---|---|---| +| Neurosymbolic core (ACL2 + Screamer + LLM bridge) | ~4,500 | Agent-generated Lisp, human-validated | Weeks — dense, well-bounded, proven approach | +| Terminal-based Stoa (editor + REPL + shell) | ~2,000 | CL-charms / cl-tty | Weeks — TUI patterns established | +| Gate rule SDK + marketplace | ~1,500 | ACL2 gate packages | Weeks — pure symbolic, well-specified | +| CFFI wrappers (system, GPU, crypto, storage) | ~2,000 | Thin bindings | Days — mechanical translation | +| Verification appliance CLI + Agora namespace | ~1,000 | API surface | Weeks | + +**Total MVP: ~11,000 lines. Timeline: 1-3 months. Human review: ~20 hours.** + +This ships. Users get verified code execution, gate rule packages, and a verified development environment. No new OS, no new browser, no Qt integration. Value proposition is proven with existing infrastructure. + +**Revenue model starts here:** domain gate packages, verification appliance, compute marketplace. The MVP is a product, not a demo. + +--- + +## Phase End State — Full Lisp Machine (cannibalize the stack) + +Replace Linux, replace C libraries, own the framebuffer, own the browser. This is the full [[file:self-driving-lisp-machine.org][self-driving Lisp Machine]] vision. + +| Phase-out target | Replacement | Lines | Scale | Risk | +|---|---|---|---|---| +| Linux kernel (scheduler, IPC, drivers) | Microcode on Tenstorrent | ~6,000 | Months — hardware-limited cycles | Verification delay; hardware bugs | +| MMU / process isolation | GC + ACL2-verified single address space | ~2,000 | Weeks — architecture already defined | Legacy app compatibility | +| Display server (X11/Wayland) | Lisp framebuffer compositor | ~4,000 | Months — visual debugging is slow | UX gaps at the edges | +| Browser (WebKit embed) | WebKit via Lisp FFI with verified wrappers | ~3,000 | Months — sandboxing the embed | Web platform surface is unbounded | +| Native browser | Full Lisp DOM + render engine | ~30,000+ | Years — browser engines are OS-scale | This is the hardest piece. Consider staying on WebKit | +| Core libraries (libc, SSL, crypto, etc.) | Incremental verified replacements | ~10,000+ | Years — can chip away post-ship | Every replacement must match SOTA perf | +| Qt / terminal / native UI toolkit | Stoa toolkit (verified compositor + widgets) | ~8,000 | Months–years | UX parity with modern toolkits is the highest risk | + +**Ballpark end state: 25,000-60,000 lines. Timeline: 2-5 years.** + +The range reflects uncertainty about the browser. If WebKit embed is sufficient (Phase Zero's terminal UX graduates to a managed WebView), the end state is closer to 25K. If you need a full native browser with verified DOM, ACL2-rendered layout, and a compositor that matches macOS fluidity — that's a years-scale project on its own. + +--- + +## Orders-of-Magnitude Risk Map + +| Decision | At stake | True scale | Mistake if treated as | +|---|---|---|---| +| Does the verification marketplace work? | Company thesis | Months (Phase Zero) | Solved in days | +| Can we ship without replacing Linux? | Time-to-market | Weeks to implement | Years of kernel work before product | +| Is WebKit embed enough for Stoa? | 60% of total timeline | Months vs years | Native browser as default path | +| Does the sufficiency flip cover each domain? | Revenue model | Weeks per domain | One-shot, all or nothing | +| Can Lisp match SOTA browser UX? | Full vision | Generations (or never) | Engineering problem, not a research question | + +The most dangerous order-of-magnitude error: treating the end state as an engineering sprint. Replacing the browser engine is a years-scale project that has defeated every attempt (Servo, PhantomJS, etc.). If that's the destination, plan accordingly — or accept WebKit embed as the terminal destination and focus verification on the OS/compositor layer where it provides real security value. + +See [[file:investment-thesis.org][Investment thesis]] for the business case and [[file:cost-structure.org][Cost structure]] for the economics behind the verification-only-first approach.