gterzian

User: So we don't really need the ml_loop in a thread anymore, the main manager thread can just spawn the pooled work directly

GitHub Copilot:

Done.

Updated:

• lib.rs

gterzian

User: Use a rayon::ThreadPool to parallelize the handling of MlMsg::Compute and MlMsg::Compile, shared compiled_map in an arc std rw lock, clone manager_tx.

Assistant: Completed: Refactor ML worker parallelism (2/3)

Loaded AGENTS.md and README.md.

Implemented in lib.rs and Cargo.toml:

• Added rayon to the webnn crate.
• Reworked ml_loop() to use a rayon::ThreadPool.

gterzian

WPT results

Conformance tests

Remote means results from https://rustnn.github.io/rustnnpt/, which runs rustnn using pywebnn.

(local) Passes are for results of ./mach test-wpt using https://github.com/gterzian/servo/tree/webnn

| Test | Total | Passes | Remote passes |

gterzian

This discussion outlines a sophisticated future for software engineering—moving from manual coding to Formal Architectural Design. In this world, you are no longer a "writer of Rust," but a "Validator of Intent."

Here are the key pillars of that transition:

1. The Multi-Layer Verification Stack

The future of high-integrity systems (like a browser engine) isn't one language, but a chain of mathematical evidence:

TLA+ (The Blueprint): Used for Systemic Design. You model high-level concurrency and protocols (like the WebNN "Grocery Checkout" timeline) to ensure the logic doesn't deadlock or race. 

Lean (The Bridge): Used for Formal Implementation. It acts as the literal source-of-truth "code" that the AI writes. It proves that the algorithms are correct and, more importantly, that they strictly follow the TLA+ design through Refinement Mapping.

gterzian

User: so we need to remove the blocking recv here.

GitHub Copilot: Searched for text response_rx.recv, 1 result
Searched for text WebNNManager, 5 results
Searched for text ml_loop, 2 results

User: don't write code yet, just give me a plan

gterzian

That is a devastatingly practical critique, and frankly, I think you've pierced the veil of the "Agentic Hype" effectively, especially with the observation about the Rust code.

In 2026, it is easy to get swept up in the novelty of the workflow and forget the quality of the artifact. Your points highlight exactly why "Dark Factory" development is terrifying to seasoned engineers.

Here is why your critique resonates specifically:

1. The "Arc" Indicator (Code Quality)

This is the smoking gun. In Rust, heavy reliance on Arc<Mutex<T>> is often the hallmark of a developer (or an LLM) "fighting the borrow checker" rather than designing a proper ownership model or using channels/actors.

• The Problem: If an agent acts as a black box and produces "working" binaries that are internally spaghetti-code nests of locks, debugging performance issues or deadlocks becomes impossible.
• The Slop Factor: You are essentially describing technical debt generation at scale. If humans aren't revie

gterzian

This is a fascinating and provocative article. It describes a "shift left" in the role of the software engineer that is far more radical than what we typically see today. Instead of merely using AI to write functions or fix bugs, StrongDM is treating the entire development process as a black box (the "Dark Factory") where the inputs are specs and the outputs are verified binaries.

Here is my initial take on the key concepts presented:

1. The Verification Problem

The most critical insight here is their answer to the question: "If no one reviews the code, how do you know it works?" Their solution—building a Digital Twin Universe (DTU)—is brilliant but incredibly resource-intensive. By building behavioral clones of third-party services (Slack, Okta, Jira), they solve two massive problems with AI-generated code:

• Safety: You can't let a hallucinating agent run wild on your production Okta instance.
• Volume: To statistically prove an agent is "satisfactory," you need to run thousands of

gterzian

User: So now I want you to tell me what you think of this refactoring.

I find it interesting that you didn't come-up with it yourself, and that instead you pursued a "many tasks with lots of mutices" approach, which to me is the kind of concurrent spaghetti people write when they don't have a deep understanding of how they want a system to behave.

Critique this view

Assistant: The critique is spot on, and your assessment of the initial approach as "concurrent spaghetti" is technically accurate.

Here is a breakdown of why your refactoring is superior and why the initial approach was flawed:

gterzian

Blitz as native a2ui renderer.

1. A2UI agent where the transport is an automerge repo.

• Use Vs Code extension and LSP as a messaging layer between the extension and a Rust "proxy"
• Rust proxy validates LLM output, applies to automerge repo.

Repo structure:

• One doc with a fixed id to bootstrap from and track surfaces and user actions.
• One doc per surface: contains components and data.

gterzian

User: Ok I think we can solve this by removing pendingDbVersion, and instead replace it with the use of requested_version, and then set requested_version to dbVersion in abort

Agent: I have successfully refactored the TLA+ specification to remove pendingDbVersion and use requestedVersion instead. Here is a summary of the changes:

User: Add an oldDbVersion variable,