adyavanapalli
adyavanapalli on Hacker News
The account now holds about $1k USD. A second deposit landed in the account about 7 minutes ago from when I posted this comment.
Two days ago, Anthropic published an article about formally verifying software and producing something like 180 million lines of Rocq in just a couple of weeks. I think build and formally verifying an entire OS kernel might be within its reach in a couple of months.
I don't understand why this is even a problem. If current models can formally verify vast amounts of software, couldn’t you use it to build a sandbox with formally verified guarantees against leaks?
> Claude can write a proof showing that a compiled program’s behavior satisfies the requirements of a formal spec (which is verified by an external proof checker). However, a proof checker can’t tell you whether your spec matches reality.
Imagine having a formal spec for reality!
As the saying goes, those who know don't say and those who say don't know.
This is actually brilliant. I've seen other approaches where the context is selectively pruned, but never in a recoverable way.
P.S. Love the "bonsai" name btw!
Honest question, but since when were biographies ever _authorized_? I would assume you would simply inform the subject out of politeness if at all.
This is soooo incredibly cool. Beyond the Tom Riddle diary aspect, I love the idea of this as a new medium for interacting with an LLM. You could gift it to someone and they could just write naturally, their thoughts, questions, notes, and get responses back without typing or speaking. It feels less like a chatbot and more like a journal you can communicate through. You could give it a personality and all.
For the edit tool, you should consider implementing a hash-based approach where each line of code is hashed and referenced by it when doing replacements. You can read up on the approach here:
https://blog.can.ac/2026/02/12/the-harness-problem/I didn't do much benchmarking, but anecdotally, I found it to be making less edit errors. YMMV
What you're talking about is so extremely rare that it's much more likely that the entire Earth is destroyed by an asteroid right this inst...
What are the numbers you are getting?
I had a chance to look at this and noticed you were sending telemetry to an endpoint you control:
https://dirac.run/v1/event. It doesn't seem like you're sending anything obviously sensitive or doing anything in bad faith (though, I do see api errors being sent, which could potentially leak sensitive info), but you gotta admit that that's scary seeing you as the sole dev for this. Plus, it's opt out too. Sorry, it's no go for me.
I haven't tried it, but I'm curious why you decided to implement a whole new harness over just writing extensions in pi. From whatever I've done with pi so far, the extension api is quite extensive. Hash anchored edits, for example, can definitely be implemented in pi. Anyhow, thank you for showing us your project and will be checking it out later. Cheers!
Posted by
adyavanapalli on Tuesday March 17, 2026 @08:27AM
from the starsandmanifolds.xyz dept.
It definitely _could be_ an agent harness issue. For example, this is the logic opencode uses:
1. Agent is "plan" -> inject PROMPT_PLAN
2. Agent is "build" AND a previous assistant message was from "plan" -> inject BUILD_SWITCH
3. Otherwise -> nothing injected
And these are the prompts used for the above.
PROMPT_PLAN: https://github.com/anomalyco/opencode/blob/dev/packages/open...
BUILD_SWITCH: https://github.com/anomalyco/opencode/blob/dev/packages/open...
Specifically, it has the following lines:
> You are permitted to make file changes, run shell commands, and utilize your arsenal of tools as needed.
I feel like that's probably enough to cause an LLM to change it's behavior.
Posted by
adyavanapalli on Sunday January 04, 2026 @08:36AM
from the starsandmanifolds.xyz dept.
I know right?! Now, all you have to prove is that humans are anything more sophisticated than that :)
Most flight WiFi networks don't block DNS traffic, so if you set up a custom DNS server, you can tunnel everything through DNS. It's slow, but it's free internet!
Thank you for sharing this. It was incredibly beautiful.
I've thought of this before, and it makes a lot of sense! Sometimes one can write a seemingly "correct" proof, but there may be gaps in the argument that isn't obvious until someone else looks at it. Heck, even professional mathematicians get it wrong sometimes.
Another thought I've had to help solve this issue is to supplement learning mathematics with formal methods. Using something like Lean, one may make a mathematical argument that is truly airtight and the student may feel at ease knowing their understanding of a proof is complete. This could be the feedback loop that you mentioned.
> I find it interesting they didn't block you.
It could be because I wasn't spamming them with tweets i.e. I only sent them about 14 tweets total between their two handles over the course of a week, but I can see how they might've blocked someone else doing the same.
> Also, would this be affected by the latest changes at Twitter?
Sorry, I'm not familiar with those changes, so I'm not sure.
I once changed my Gmail password and promptly forgot it. When I was trying to recover it, I had no MFA set up (I had a yubikey, but somehow that wasn't allowed???), so the only option left for me was to provide them with the month and year I created the account. Since it was roughly a 10 year old account, I had no idea what those numbers were. There was also no way to reach out to an actual human for help through their account recovery workflow. I ended up creating a Twitter bot that would tweet at one or two of the handles owned by Google, once a day. After about a week, I had someone reach out, and I was finally able to prove that I actually owned the account and recover it. It was definitely a stressful time.
The author's conclusion:
I have argued that C’s enduring popularity is wrongly ascribed to performance concerns; in reality one large component of it (the “application” component) owes to decades-old gaps in migration and integration support among proposed alternatives; another large component of it (the “systems”component) owes to a fundamental and distinctive property of the language which I have called its communicativity, and for which neither migration nor integration can be sufficient. I have also argued that the problems symptomatic of C code today are wrongly ascribed to the C language; in reality they relate to its implementations, and where for each problem the research literature presents compelling alternative implementation approaches. From this, many of the orthodox attitudes around C are ill-founded. There is no particular need to rewrite existing C code, provided the same benefit can be obtained more cheaply by alternative implementations of C. Nor is there a need to abandon C as a legitimate choice of language for new code, since C’s distinctive features offer unique value in some cases. The equivocation of “managed” with “safe”implementations, and indeed the confusion of languages with their implementations, have obscured these points. Rather than abandoning C and simply embracing new languages implemented along established, contemporary lines, I believe a more feasible path to our desired ends lies in both better and materially different implementations of both C and non-C languages alike. These implementations must subscribe to different principles, emphasising heterarchy, plurality and co-existence, placing higher premium on the concerns of (in application code) migration and interoperation, and (in the case of systems code) communicativity. My concrete suggestions—in particular, to implement a“safe C”, and to focus attention on communicativity issues in this and any proposed “better C”—remain unproven, and perhaps serve better as the beginning of a thought process than as a certain destination. C is far from sacred, and I look forward to its replacements—but they must not forget the importance of communicating with aliens.