EDIT: Now worth $2k
266 karma · joined February 9, 2017
EDIT: Now worth $2k
Imagine having a formal spec for reality!
P.S. Love the "bonsai" name btw!
I didn't do much benchmarking, but anecdotally, I found it to be making less edit errors. YMMV
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.
[1]. https://twitter.com/VishnuKVMD/status/1253324405813284868?t=...
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.
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.
[1]: https://www.wnycstudios.org/podcasts/radiolab/articles/28257...
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.