Your best bet will be to start a network optimized ec2 (or gcp compute instance) and save to some bucket. Cloud network will be a lot more stable than home.
You can't please everyone on the internet, if he had posted this on Arxiv then someone else will be complaining that Arxiv is for humans to publish and that llm output should be social media post instead. Also, the proof fits in a tweet. So why blow it up.
that's because they said they'll silently fallback in case of model training. Then they backtracked, and said they wont silently fallback, but how will anyone ever know?
My daughter suffers from Autism Level 3 and I worked with my daughter's speech therapist and OT to build tejutalks.com which helps nonverbal children communicate with the help of AI.
It's being used by around 10 kids for the last 3 months and it's really helped some of them to demonstrate that they know a lot more than they can say.
It uses Openai models underneath, although initially I started with local inference using MLX. If anyone is curious feel free to reach out.
Hi, thanks for the writeup, I wonder for the auth problem what you think about rego and OPA type solutions and their place in world in comparison to generated guards?
Definitely connected; OPA is itself a structural gate, but at runtime. The post focused on compile-time gates, but there's no reason a structural gate can't run at runtime — which means they compose rather than compete.
I didn't get into this in the post, but Shen is extremely portable and has been ported to a lot of different target runtimes (Go, C, Lisp, JS, many others — https://shen-language.github.io/#downloads). But, OPA offers extremely fast runtime execution in a way that would be more difficult to get to in Shen. What the compile-time guard adds is that it can make the runtime invocation non-skippable — so you could have a compile-time assertion that the code calls the runtime assertion, with OPA sitting behind the constructor. The catch is that if you still want all your invariants in Shen but use OPA for the runtime layer, that's another translation layer to keep in sync (Shen → Rego alongside Shen → guards). The alternative is to lean on Shen's portability: you could run the same spec at runtime with no translation layer at all, trading OPA's speed for that simplicity. Either way they're similar concepts run at different times. Integrating both into one high-level spec is mostly a question of which of those tradeoffs you want.
No it's not. Where do you come up with this? Just because you searched the phrase on Google and there's a single result for it on a wiki? Who do you know that's using this expression regularly?
I’m not them but we have vastly improved our internal pipeline monitoring/triage/root cause/etc by having a new system that basically its whole purpose is to hook into all of our other systems and consolidate it under a single view with an emphasis on shortening the amount of time it takes to triage and refine issues.
This will have previously been too ambitious to ever scope but we’ve been able to build essentially all of it in just two months. Since it sits on top of our other systems and acts as more of a window/pass through control pane, the fact that it’s vibe coded poses little risk since we still have all the existing infrastructure under it if something goes awry.
> ... the person next to him is probably also a combatant
Absolutely, they could even be future combatants even if they are not now. That's why killing schoolgirls in Iran, reporters in Lebanon, etc. is justified, they are all potential terrorists. It definitely can not be proven otherwise that they are not. Why take a chance? /s
Building VizPy, a prompt optimizer we've been working on for a while now.
The problem it's solving is one most people building with LLMs know well. Your prompt fails on some inputs, you don't really know why, and you end up just tweaking and re-running until something sticks. We kept hitting this ourselves and it felt like there had to be a better way than guessing.
What we figured out after a lot of research: prompt failures almost always follow a pattern. The model isn't failing randomly, it's consistently failing on a particular type of input or reasoning step. VizPy finds that pattern, distills it into a plain English rule you can actually read, and then rewrites your prompt around it. You also get the rule itself so you can review it, tweak it, or just drop it into your existing prompt directly. DSPy-compatible, no pipeline rewrite needed.
We have compared it extensively against baselines such as GEPA on benchmarks like BBH, HotPotQA, GPQA Diamond, and GDPR-Bench and VizPy wins on all of them. We'll have more benchmarks on cyber-security and chip-design coming out soon.
