And in terms of interesting use cases: recently pointed an agent at Blender and gave it vision. That setup can essentially iterate on a scene forever.

It was truly remarkably easy to build and package it exactly to my whims, in my case as a single docker container with a process reaper that runs llama, my Go code, tts, chat harness, browser in xvfb, and even a mailer daemon. With Gemma, it even runs on a RPi 5.

What’s absolutely wild to me is that over a couple hours, I could probably have it import parts of Home Assistant for my devices directly, and do other wacky stuff in what is essentially software for one.

https://www.overplane.dev/ (Apache-2.0)

Like many others, I’ve watched AI code pile up at work, and get increasingly lighter reviews due to its size and maddening uniformity. On my side projects at night, I see the full speed and fragility of vibe coding. Neither practice seems sustainable, so I’ve been playing around for the last few months looking for a balanced, middle ground.

The key idea here is similar to chip design: if AI written software functionally does what you intended it to (by virtue of increasingly sophisticated testing against a codification of your intent), then it’s perhaps less important to manually review every line of generated code.

Overplane is a labor of love that brings that idea to life as an open-source experiment, combining some old personal loves: containerization, content addressed build systems, and formal verification.

The example I’d start with is rustdis, a partial, wire-compatible Redis clone in Rust with an empty [dependencies] section. Created with seven short specs and about $45 of Claude Opus, in about three hours: https://www.overplane.dev/examples

What sold me on the approach is that the one IR generated by Overplane from the specs paid for itself downstream: Z3 checks at build time, 48 generated proptest properties, and Kani proofs on the parser and arithmetic core.

It also holds up against redis-benchmark better than I expected, within about 90% of real Redis on my box unpipelined and a bit ahead on some pipelined workloads, which I mostly attribute to rustdis doing less than Redis does.

It’s v0.0.8 and rough. If you’ve tried spec-first workflows or lightweight formal methods in anger, I’d love to hear where they broke down for you.

Comments URL: https://news.ycombinator.com/item?id=48894426

Points: 4

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=48877337

Points: 4

# Comments: 0

For me in a similar vein:

- mar ‘24: thinking about how to survey the field and implement a hard research task in Natural Language Processing, and then just approximating it well enough with a prompt and a completions api

- mid ‘25: Llama 3 being able to analyze a good sized codebase I was onboarding onto, and synthesize it into diagrams that matched the quality of ones I’d generated by hand with deterministic tools.

- dec ‘25: opus 4.5 basically generating multi-class modules and tests perfectly (syntactically). Finding that errors were my own under-specification of the prompt. Stopped writing code by hand, mainly because it was good enough and came with tests, docs, build scripts, and other goodies for free.

Sounds like it’s been written specifically to avoid liability.

> One of the biggest constraints on the retrieval implementation is latency

If I’m getting a multi line block of code written automagically for me based on comments and the like, I’d personally value quality over latency and be more than happy to wait on a spinner. And I’d also be happy to map separate shortcuts for when I’m prepared to do so (avoiding the need to detect my intent).

This is outdated information, and not required anymore when using CloudFront.

And even in the past, you could use the S3 API to implement a reverse proxy without matching bucket and domain names.

Depends what you’re estimating. The minimum is usually not representative of “real world” performance, which is why we use measures of central tendency over many runs for performance benchmarks.