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,

gterzian

The Glass Box: A Servo-Based Generative UI Sandbox

Agents can already run code locally. What they still can’t do—safely and ergonomically—is show and allow interaction with their work.

The Problem: Secure Execution vs. Interactive Output

In practice, today’s approaches force a tradeoff (see A field guide to sandboxes for AI):

1. Secure execution, weak UX Containers, MicroVMs, and Wasm sandboxes are great for isolating compute, but they’re often headless in practice: the user gets logs, diffs, and text.

gterzian

This PR adds a tla+ spec for the transaction lifecycle logic.

Background: I am involved in the efforts at Servo to implement the 3.0 spec, and I found myself struggling with how the concurrency around transaction lifecycle is specified. In particular, I found it hard to reason about how upgrade transactions interact with each other and with other types of transactions.

For example, to figure out upgrade transactions exclude any other transaction, you have to look around the spec at things like step 1 of https://w3c.github.io/IndexedDB/#dom-idbdatabase-transaction, and the fact that https://w3c.github.io/IndexedDB/#opening waits for all other connections to close before proceeding with https://w3c.github.io/IndexedDB/#upgrade-a-database.

There is also some subtlety on how the connection queue and the various "wait" interact: the "Wait until all connections in openConnections are closed" at https://w3c.github.io/IndexedDB/#opening, and the "Wait for transac

gterzian

Opportunity in GenUI

MakePad genui: dev defines widget library(framework defines standard widgets), Ai generates ui on the fly based on context.

Apply to Robrix Ai chat by defining widgets and having them generated by the Ai on the fly.

The most basic widget is just text, corresponding to a text-only reply. Others could be whatever makese sense for the app(draft message with "send to chat" button)?

Requires a way to insert widget dynamically into the UI. With Makepad I guess that means using shaders or the re-load functionality. On the web it would be a trivial manipulation of the DOM.

gterzian

Here is a summary of the conversation log regarding the Moly project:

1. Rebranding and Naming

• Name Change: The team decided to rename the app from "Moly" to "Moly AI" because "Moly" and "MolyApp" were already taken in the App Store.
• Domain & Bundle ID: The domain moly.ai is taken by a different AI product. The team settled on org.molyai.app for the Apple Bundle ID.
• Website: A landing page was published at moly-ai.ai, though some performance issues (lag on Firefox, GPU spikes) were noted.

2. Mobile Development (iOS & Android)

• TestFlight: Julian successfully set up TestFlight for iOS beta testing. There were initial hurdles with "External Tester" access due to a missing ITSAppUsesNonExemptEncryption key in the plist.
• Known Issues:

gterzian

Robrix

Ai utility chat

Separate chat for interaction with an LLM using tools in the context of the Robrix app. Note that while this can appear as a chat history to the user, it should not be constructed as such, in order to avoid prompt injection pitfalls in the context of LLM tool use.

Features:

• connect with an LLM(local or remote).