camdenclark

Do you have the raw data for this export? The forum post lists on the site don't seem to have all the historical content so I can browse.

All I was able to find is that "we are the hunted" was a slogan/tagline on the site back in the day!

I really vaguely remember this one. I think the reason it might not be archived is it was behind a sign-in on srl-forums.

I'm going to try to find it and get back to you.

This and Simba with SRL. Was a really awesome learning experience and totally formative to becoming an engineer.

I don't think anyone has written online about what these communities were like and how interesting they were. I should do it!

Yep I got started with programming with SCAR and on srl-forums with SRL as well. Was really fun.

Looks excellent, looking forward to trying this out. Feels like we're reaching a critical point where these become competitive.

The main way this analogy doesn't hold up to me is that your house is mostly static -- you're not rebuilding the walls, adding new doors or windows constantly.

But in software, especially with agents, we're constantly renovating the house. If you were renovating every 6 months I'd expect to find more places to seal up, even if you were following best practices in those remodels.

That being said, I do think we will reach an equilibrium where most vulnerabilities are found at PR time.

Separate but if you run CI at any scale you should have an agent working to improve CI constantly and alert you to any regressions / flakiness. It's something that agents can do in the background and open PRs for your team.

You need blocking!

Fundamentally this is an entity resolution problem. An LLM can score pairwise really well but scoring all the pairs would be insanely computationally difficult.

If you can constrain the set of potential matches up front by querying the dataset for things that could be matches it gets a lot more tractable to use an LLM for this.

Are there any heuristics you can use to reduce the search space? You mentioned soundex transformation and maybe prefixes of last names could work? Even if you get the number of potential matches down by a few orders of magnitude this gets more reasonable!

Check out https://moj-analytical-services.github.io/splink/index.html

Absolutely the first one could be achieved using one of those tools. But Monty makes it feel so native, it even packages a type checker so you can provide stubs for the external functions (so you provide feedback to the agent on the type of those things).

Serializable state is the most cool property though. It's really undersold in the explanations but makes running durable agent workflows authored in code possible!

The main property that's really important is that Monty VM state is fully serializable and resumable. So you can run the VM code until you get to a host call, then serialize and persist the state to disk. Then, at a later time you can resume the VM with the tool call results.

Even Luau (which was made for sandboxing user code) don't really have this property.

1. Control and guardrails. I want agent-authored code to be able to express itself in code but I want to own the external tools that are available to the agent.

2. Suspension and resumption. Monty's VM state is fully serializable so I can run the VM until it gets to a tool call and persist the VM state. I could resume it days later with the results of the tool call with no issues. Doing that guaranteed with CPython is really tricky (tools like Pickle can get you close but if you have open sockets or other weird stuff you're in a world of hurt).

Funny -- I just built a pure go wrapper myself because this one is super out of date!

https://github.com/CamdenClark/monty-go

It implements the new subprocess model for spawning Monty VMs that help keep your main thread isolated if one of the VMs crashes.

Because Monty is packaged as a binary now, you don't need to do the WASM embedding stuff, you just need to make sure you have the binary. (Similar to how you would run playwright in Go, for example)