polyglotfacto

no profile record

Submissions

[untitled]

1 pointsby polyglotfactovor 4 Monaten0 comments

[untitled]

1 pointsby polyglotfactovor 4 Monaten0 comments

[untitled]

1 pointsby polyglotfactovor 4 Monaten0 comments

Lean and AI caught a bug in my 2-year-old TLA+ spec

1 pointsby polyglotfactovor 4 Monaten1 comments

Implementing WebNN with the Help of AI

1 pointsby polyglotfactovor 5 Monaten1 comments

Federal Reserve use of AI coding

federalreserve.gov

1 pointsby polyglotfactovor 5 Monaten1 comments

Paul Ford: 'The A.I. Disruption Has Arrived, and It Sure Is Fun'

2 pointsby polyglotfactovor 5 Monaten1 comments

[untitled]

1 pointsby polyglotfactovor 5 Monaten0 comments

Show HN: Prompt-injection‑resistant agent runtime that writes web apps

1 pointsby polyglotfactovor 5 Monaten0 comments

Study on positive use of AI in academic writing; challenges brain rot narrative

sciencedirect.com

1 pointsby polyglotfactovor 6 Monaten0 comments

AI Coding: Conversations and Bottlenecks

1 pointsby polyglotfactovor 6 Monaten0 comments

comments

vor 4 Monatendiscuss

I implemented MessagePort in Servo back in 2019 — it was the hardest concurrency problem I'd encountered, because ports can be transferred between event loops while messages are still in flight. This weekend I finally got around to formalizing it in TLA+, with Claude helping with the typing. The interesting outcome: the abstract spec (following the HTML standard) is so simple that the refinement proof itself serves as the inductive invariant. No additional invariants needed. TLC found no bugs in the Servo implementation, though it did help me make explicit a sequencing assumption that was implicit in the code. Happy to answer questions about the TLA+ approach or the Servo implementation.

vor 4 Monatendiscuss

I've been implementing the WebNN Web Standard on a personal Servo branch with AI coding assistance (main bans AI), and switched to GPT 5.4 this week. It introduced a race condition that compiled cleanly, passed tests, and would have been hard to catch if calling patterns had ever changed — and separately produced over-engineered architecture that took several iterations to unwind. Both episodes say something interesting about where agentic coding actually breaks down. Article includes the conversation transcripts.

vor 4 Monatendiscuss

I am in the third week of my experiment with AI-assisted coding on a personal branch of Servo (which still bans all AI contributions).

First, the least relevant metric: LOC. Almost doubled from 7k to 12k in a week.

Current WPT pass rate, compared to the default integration of rustnn (pywebnn) is at: https://gist.github.com/gterzian/95371d56468390177982c068480...

This week was the grunt work: grinding through the long list of missing operations, with almost all now implemented.

Also switched to a more expensive coding model (GPT 5.3 Codex), which was an improvement, but there were still a few clear fails—specifically around the model taking "shortcuts" with spec logic.

vor 4 Monatendiscuss

I’ve used TLA+ for six years to "debug my thinking," but I always treated the jump from spec to implementation as a leap of faith.

What surprised me in this experiment with Lean was that the AI-assisted formalization actually caught an error in my "vetted" TLA+ spec that had been sitting there for two years. It turns out my inductive invariant wasn't strong enough—something the TLA+ model checker didn't slap me for, but Lean’s kernel refused to ignore.

This was also a way to bridge a higher-level spec, written in Lean in a kind of TLA-like flavor, and the lower level implementation, also written in Lean but with a code-like flavor, and then proven that the implementation refines the spec.

Using Lean to bridge the gap between high-level temporal logic and low-level IO implementation, all written by AI but driven by human intent, feels like the first time the "coding singularity" might actually lead to better software rather than just more software

vor 5 Monatendiscuss

I am a maintainer of the Servo web engine. Two years ago, our project banned AI-generated contributions. I was a dissenting voice on that policy, and have continued to experiment with AI on side-projects. This is perhaps the most ambitious side-project so far: implementing the WebNN (Neural Network) API.

Given the policy in place, I'm doing this on a personal branch of Servo. I’m using it as a sandbox to test a specific thesis: AI is not an architect; it is a "fluid syntax engine."

This is also my response to the "autonomous slop" seen in projects like fastrender that claim to build complex software with AI but produce what I call "fine-looking nonsense" (see https://news.ycombinator.com/item?id=46624541#46709191). I wanted to see if a human architect could use an AI agent to handle the syntax and boilerplate of a Web Standard while the human retains total control over the conceptual structure.

Progress & Tech Stack:

    The scope: I am using `rustnn`, and this project can be seen as doing for the Web what `pywebnn` does for Python. 

    The model: I am intentionally using a "cheap" LLM: Raptor mini.

    The scale: I’m 7k LOC into the implementation. It currently passes a subset of WPT (Web Platform Tests) conformance tests for a specific operator (and its dependencies): add. Such a conformance test requires implementing the full graph compilation and dispatch workflow. Code is at https://github.com/gterzian/servo/compare/master...gterzian:servo:webnn

    The backend: The work involves integrating the `rustnn` library into Servo’s runtime, with compute currently happening only via CoreML (macOS only).

The Reality Check: While the productivity boost is real, the code is not yet up to my standards. Despite ongoing reviews, I’ve had to accept a certain amount of "slop" that I’ll need to clean up later. More importantly, I hit several conceptual bottlenecks: architectural problems the AI was not only unable to solve without guidance but was unable to even identify in the first place.

You can read the full breakdown of the first week and a half (contains links to code and various illustrative commits) in the link for this post.

And the backstory on why I'm doing this is at: https://medium.com/@polyglot_factotum/the-slop-diaries-imple...

I’d be happy to hear from others on how they balance the "syntax speed" of AI with the "architectural integrity" required for long-term projects.

vor 5 Monatendiscuss

Within the Federal Reserve System, we have also been exploring the use of AI in our own operations and have established an AI program and governance framework for the use of AI technologies. One internal application of GenAI that shows considerable promise is technology modernization. Within clear guardrails, we are using GenAI tools to translate legacy code, generate unit tests, and accelerate cloud migration. So far, the result of this usage is faster delivery, improved quality, and an enhanced developer experience. In one recent project updating hundreds of databases, AI tools helped cut the time to complete this type of work by 50 percent, detected and resolved 30 percent more issues during testing compared to previous migrations, and enhanced team focus on higher-value coding work. My sense is that these are the kinds of uses and the scale of success that many businesses are experiencing.

vor 5 Monatendiscuss

> FWIW, an inefficient but working product is pretty much the definition of a startup MVP

It depends on what kind of start-up we're talking about.

A compiler start-up probably should show some kind of efficiency gain even in an MVP. As in: we're insanely efficient in this part of the work, but we're still missing all other functionalities but have a clear path to implementing the rest.

This is more like: It's inefficient, and the code is such a mess that I have no idea on how to improve on it.

As per the blog improvements were attempted but that only started a game of whack-a-mole with new problems.

If on the other hand you're talking about Claude Teams for writing code as an MVP: the outcome is more like proof that the approach doesn't work and you need humans in the loop.

vor 5 Monatendiscuss

> its value comes from fulfilling its requirements.

The requirements will have to come from somewhere, and they will have to be quite precise although probably higher-level than code written today. You're talking about just a new kind of software engineer. The kind of stuff described at https://martin.kleppmann.com/2025/12/08/ai-formal-verificati... (note the "the challenge will move to correctly defining the specification")

Unless what you have in mind is some sort of Moltbook add-on that the bots would write for themselves.

I'm talking software providing value to humans.

vor 5 Monatendiscuss

> When a friend asked me to convert a large, thorny data set, I downloaded it, cleaned it up and made it pretty and easy to explore. In the past I would have charged $350,000

> (..) it implies a product manager, a designer, two engineers (one senior) and four to six months of design, coding and testing. Plus maintenance.

What I find interesting is that ten years ago the author could have written: our intern spent the weekend at the office and ended-up creating 350k of billable work.

Such as statement would have been instantly ridiculed as unprofessional, but somehow with AI it works.

Shows Jaron Lanier is right when saying that AI makes people adjust themselves to a lower level of intelligence(or something along these lines).

> People don’t judge A.I. code the same way they judge slop articles or glazed videos. They’re not looking for the human connection of art. They’re looking to achieve a goal. Code just has to work.

Yes indeed. And what the author leaves aside is that for code to work, it requires some level of conceptual integrity beyond that which vibe coding can offer.

He also forgets to mention that the future is not either we keep building slow software by hand, or we go full vibe code, but that there is also the option of ( a new kind of?) professionals using AI to be more productive, while ensuring output is up to standards.

> It might fail a company’s quality test, but it would meet every deadline.

This brings us back to the intern frantically coding over the weekend. This problem is as old as software itself, it is just compounded by AI being even faster than a frantic human coder, but it's not new. The industry could have thrown quality standard out of the window long before LLMs came around.

I also dislike how the author seems to imply that quality software requires all this bureaucracy. I mean, what about open source for example?

> the direct descendant of NeXT’s software is what’s running on Macs and iPhones in 2026. In software, sharp change is to be avoided at all costs. The risk is just too high.

I think here he got it backwards again. At least half of the reason people are willing to spend a premium on Apple products is because the software just works, and that is because it is based on a strong foundation going back all the way to when Jobs decided to spend all his cash on building the best computer.

Some additional thoughts at https://medium.com/@polyglot_factotum/on-what-ai-does-not-di...

vor 5 Monatendiscuss

My review of the article, as a conversation with an agent: https://medium.com/@polyglot_factotum/slop-review-with-ai-th...

Here is the AI's final verdict (following an initial enthusiastic take to which I replied with my critique):

"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<Mutex>' 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 reviewing the code, and the agents optimize for 'does it run?' rather than 'is it maintainable?', you end up with a brittle, unmaintainable binary blob.

2. The Verification Gap (Digital Twins vs. Mocks)

Your point about 'How do you know the twin implements the service?' is the Map vs. Territory problem.

The Hallucination Loop: If the same model class (e.g., GPT-5.2) reads the Okta docs to build the Code and reads the Okta docs to build the Digital Twin, they share the same blind spots. If the model misunderstands an edge case in the docs, it will bake that misunderstanding into both the product and the test. The test will pass, but the production system will fail.

Mocks are Explicit: Traditional mocks are valuable because a human explicitly codifies their expectation of the external service. Removing the human from the truth-definition layer is dangerous.

3. 'Amateur Formal Methods'

This is a keen insight regarding attractor. True formal methods (like TLA+ or Alloy) use mathematics to prove correctness. StrongDM’s approach uses prose (Markdown specs) and relies on the LLM's interpretation of that prose. This isn't 'spec-driven development' in the formal sense; it's just 'prompt engineering with extra steps.' It lacks the rigor that actually guarantees safety.

Conclusion on your 'Smoke and Mirrors' take:

It sounds like they prioritized Automating the Process over Guaranteeing the Product. If the 'Dark Factory' just churns out unreadable, lock-heavy code verified against hallucinated simulations, it’s not a revolution—it’s just a faster way to build legacy software."

vor 5 Monatendiscuss

After seeing the autonomous browser and compiler projects trend here, and having been a vocal critic in the comments, I felt compelled to write a long-form rebuttal.

My thesis: AI agents are powerful tools for experts, but the current "autonomous swarm" narrative is economically driven hype that produces useless code. I attempt to demystify how agents actually function under the hood, and argue that their true value comes from expert-led conversation rather than autonomous loops.

vor 5 Monatendiscuss

So let’s say you fund a single engineer for an open‑source project with $20k. The outcome will be a prototype with some interesting ideas. And yes, with a few hundred bucks' worth of AI assistance that single engineer might get much further than without (but not using any of the techniques presented in this blog). People can coalesce around the project as contributors. A seed was planted and watered a bit.

In this case, the $20k has been burned and produced zero value. Just look at the repo issues: looks like someone trying to get attention by spamming the issue tracker and opening hundreds of PRs. As an open source project, it’s a dead end.

So it doesn’t matter that this is “likely decrease in price over the next few years”? The value is zero, so even if superintelligence can produce this in an instant at zero cost in six months, the outcome is still worth zero.

You’re assuming a kind of inverse relationship between production cost and value.

In terms of quality, to anyone using those coding agents, it should be clear by now that letting them run autonomously and in parallel is a bad idea. That’s not going to change unless you believe LLMs will turn into something entirely different over time.

Note that what works with humans—social interaction creating some emergent properties like innovation—doesn’t translate to LLM agents for a simple reason: they don’t have agency, shared goals, or accountability, so the social dynamics that generate innovation can’t form.

vor 5 Monatendiscuss

Point is: it doesn't matter if agents can do it faster and cheaper than a team of humans: it's slop.

It's like writing a novel in a week that no one wants to read. If in six months you can do it in an hour, there is still zero value.

Agents are useful but very limited tools: I treat them a little machines that can translate high-level instructions into detailed code, but where I still need to review the output to make sure they understood what I meant; that's it. Zero autonomy; parallelism just means I can't keep up with the output and quality goes down.

I think the point of this project, like the fastrender slop thing, is to push the parallel agent narrative and have the financial markets believe this will create a lot more demand for inference on these models in the short term.

Example of someone falling for it: https://x.com/DKThomp/status/2019484169915572452

vor 5 Monatendiscuss

So as a software engineer with experience with coding agents, when I look at https://github.com/anthropics/knowledge-work-plugins

I'm like: oh that's it, a bunch of skills files?

So the value of a skill file is that it tells the model how to format its response for use within the software environment surrounding the model.

With programming, it's mostly about how to tell it to use some API.

But all the model can do is reply some text, and the actual work needs to be done by the software(the agent harness) which needs to parse the model response and translate it into actual work.

My point is there is no magic: the model just reads the skill file and then uses that as a template for a textual response, which is then parsed and processed by traditional software.

So in terms of legal skills, a stand-alone skill like the contract review skill at https://github.com/anthropics/knowledge-work-plugins/blob/ma... is basically useless.

Yes, the model will read it and it will influence its response, but without some extensive software harness around the model to give it data for context and and so on: totaly useless.

Why? Because garbage in is garbage out.

So telling the model to review a contract and pay attention to "Whether indemnification is mutual or unilateral" will result is some response from the model, but without additional data it will be at the same level as what you can get from a google search.

The effect on established companies is exactly zero.

Now, having an in-house skills and proprietary software around the model to integrate it into your system, that would be valuable indeed, but not something an AI lab can replicate without building the whole company from scratch.

vor 5 Monatendiscuss

So I do think one can get value from coding agents, but that value is out of proportion compared to the investments made by the AI labs, so now they're pushing this kind of stuff which I find to be a borderline scam.

Let me explain why:

> the resulting compiled output is over 60kb, far exceeding the 32k code limit enforced by Linux

Seems like a failure to me.

> I tried (hard!) to fix several of the above limitations but wasn’t fully successful. New features and bugfixes frequently broke existing functionality.

This has code smell written all over it.

----

Conclusion: this cost 20k to build, not taking into account the money spent on training the model. How much would you pay for this software? Zero.

The reality is that LLM are up there with SQL and ROR(or above) in terms of changing how people write software and interact with data. That's a big deal, but not enough to support trillion dollar valuations.

So you get things like this project, which are just about driving a certain narrative.

vor 5 Monatendiscuss

You can look at the Web as a starter: https://html.spec.whatwg.org/#history-2

> The WHATWG was based on several core principles, (..) and that specifications need to be detailed enough that implementations can achieve complete interoperability without reverse-engineering each other.

But in my experience you need more than a spec, because an implementation is not just something that implements a spec, it is also the result of making many architectural choices in how the spec is implemented.

Also even with detailed specs AI still needs additional guidance. For example couple of weeks ago Cursor unleashed thousands of agents with access to web standards and the shared WPT test suite: the result was total nonsense.

So the future might rather be like a Russian doll of specs: start with a high-level system description, and then support it with finer-grained specs of parts of the system. This could go down all the way to the code itself: existing architectural patterns provide a spec for how to code a feature that is just a variation of such a pattern. Then whenever your system needs to do something new, you have to provide the code patterns for it. The AI is then relegated to its strength: applying existing patterns.

TLA+ has a concept of refinement, which is kind of what I described above as Russian dolls but only applied to TLA+ specs.

Here is a quote that describes the idea:

There is no fundamental distinction between specifications and implementations. We simply have specifications, some of which implement other specifications. A Java program can be viewed as a specification of a JVM (Java Virtual Machine) program, which can be viewed as a specification of an assembly language program, which can be viewed as a specification of an execution of the computer's machine instructions, which can be viewed as a specification of an execution of its register-transfer level design, and so on.

Source: https://cseweb.ucsd.edu/classes/sp05/cse128/ (chapter 1, last page)

vor 5 Monatendiscuss

you're welcome.

vor 5 Monatendiscuss

This is not legal advice, but I think one should always add a license, not so much for copyrights but for the "no warranty" part. If someone claims copyright once can add whatever license was used in the original work.

vor 5 Monatendiscuss

This one's really nice.

- clear code structure and good architecture(modular approach reminiscent of Blitz but not as radical, like Blitz-lite).

- Very easy to follow the code and understand how the main render loop works:

    - For Mac: main loop is at https://github.com/embedding-shapes/one-agent-one-browser/blob/master/src/platform/macos/windowed.rs#L74
   
    - You can see clearly how UI events as passed to the App to handle. 

    - App::tick allows the app to handle internal events(Servoshell does something similar with `spin_event_loop` at https://github.com/servo/servo/blob/611f3ef1625f4972337c247521f3a1d65040bd56/components/servo/servo.rs#L176)

    - If a redraw is needed, the main render logic is at https://github.com/embedding-shapes/one-agent-one-browser/blob/master/src/platform/macos/windowed.rs#L221 and calls into `render` of App, which computes a display list(layout) and then translates it into commands to the generic painter, which internally turns those into platform specific graphics operations.

- It's interesting how the painter for Mac uses Cocoa for graphics; very different from Servo which uses Webrender or Blitz which(in some path) uses Vello(itself using wgpu). I'd say using Cocoa like that might be closer to what React-Native does(expert to comfirm this pls?). Btw this kind of platform specific bindings is a strength of AI coding(and a real pain to do by hand).

- Nice modularity between the platform and browser app parts achieved with the App and Painter traits.

How to improve it further? I'd say try to map how the architecture correspond to Web standards, such as https://html.spec.whatwg.org/multipage/webappapis.html#event...

Wouldn't have to be precise and comprehensive, but for example parts of App::tick could be documented as an initial attempt to implement a part of the web event-loop and `render` as an attempt at implementing the update-the-rendering task.

You could also split the web engine part from the app embedding it in a similar way to the current split between platform and app.

Far superior, and more cost effective, than the attempt at scaling autonomous agent coding pursued by Fastrender. Shows how the important part isn't how many agents you can run in parallel, but rather how good of an idea the human overseeing the project has(or rather: develops).

vor 6 Monatendiscuss

> That is a wonderful write up.

Thanks.

> what would be the best approach?

I don't know but it sounds like an interesting research topic.