lopopolo

You can read the receipts in the linked source material yourself. I’ve also read and signed off on every word in this anthology. Try it before you knock it?

But yes, 100% of the content of this repository was written by GPT-5.6 Sol Ultra.

The models are very good now so the feedback cycle on these meta adjustments is much tighter. Yesterday I was able to one shot a Liquid Glass, HIG-compliant and localized DICOM image viewer (frame by frame and looping video) with Apple Intelligence for de-jargoning the series details. Took 30 minutes. But the app had 60% CPU because it was not caching the decoded JPEGs. I can do a point in time fix for that of course, but the more interesting thing is why that misaligned code was permitted to be generated in a “done” artifact in the first place. What other misaligned code from a perf perspective might there be? And how do I intervene into the system that produced this software to make these misalignments statically not meet acceptance criteria?

Basically yea. It is the only way to learn how to outrun your priors on what “high ambition” looks like. The labor that goes into implementation is an uncapped resource now.

And to address your broader question, yes this is a form of RSI and to me a vastly superior approach to fine tuning since it allows adopting new model releases without throwing anything away while still having the same effect on improving adherence to local acceptance criteria.

Your example is super amenable to vibing some tests. As an example, I’ve been able to ban `number` from representing a duration by walking the AST in a linter to fail if var or param names that look like the end in millis or ms or sec appear. This is largely good enough. If you see that “drifting” behavior appear more than once, you have enough to stop and force the agent to write some static verifiers that reject all but the option you want. For a closer example, we did this with zod schemes and their corresponding inferred types to be universally ZPascalCase and PascalCase instead of camelCaseSchema and CamelCase

Your “really cheap” agents can’t be so cheap that they do not have good tool calling skills. But! Using bigger models to put guardrails in place as static verifiers allows lower complexity changes to “self steer” as tests fail, which means coming down on the cost curve is more effective.

Glad to hear it! Good luck, have fun. The agents tend to do a pretty good job incorporating these ideas. This was an unexpected thing we learned when publishing the initial harness engineering post.

Hi folks, author here and also author of the seminal OpenAI blog on this topic. Let me know how I can help you all let it rip.

The mruby VM as used in Artichoke uses Artichoke's Rust implementations of `String`, `Symbol`, and `Array` (and many other core classes, these ones just happen to be used by the VM itself). The symbol table (which is an essential part of how classes and methods and `send` are implemented) is implemented using the `intaglio` crate which is part of the Artichoke project.

These implemented-in-Rust bits expose themselves to the remaining C with `extern "C"` APIs written in Rust that maintain ABI compat with the mruby code they replace.

The mruby VM is getting eaten by the Rust parts, so I don't think it's quite fair to say that Artichoke uses mruby as an off the shelf component. To fully move beyond mruby though to a native Rust VM will take time.