Reactions from ranked influencers
6 posts
An appeal If you're working on an AI lab, read this and your next model will be 10x smarter. I promise you. So, please, listen to what I have to say. Nobody knows what intelligence truly is. We just know models are converging to being smarter, as they train. Yet, we DO know some of the fundamental features of intelligence. And when one of these features is neglected or not trained for, then there is no way for a model to obtain it. Neglecting an aspect of intelligence hinders a model's general capabilities, in a way no amount of flops can compensate for. I'm making this whole post to convince you there is ONE fundamental aspect of intelligence that YOU are neglecting, underestimating, and under-training for. Anyone using models 24/7 can see this weakness. It is blinding, glaring, as clear as skylight. That feature is: ✨ erasure ✨ Garbage collection. Compression. Removal. Models are not sufficiently trained for that. They are trained to ADD information. Not to REMOVE it. You ask a question. They give you an answer. They work in a project. They add files. You post a bug. They add a solution. They're only indirectly, if at all, rewarded for removing information, or compressing information. This is a huge mistake, because erasure is a cornerstone of intelligence. The human brain has several mechanisms entirely dedicated to removing information. Short term memory, long term memory, sleep, all mechanisms to throw garbage away. Furthermore, grokking is nothing but a compression event. An aha-moment happens when your brain is capable of expressing new information in terms of information you already posses stored. This is what allows that info to be stored. That is how you learn. Erasure isn't a small feature, erasure is *THE* underlying driver of intelligence. It is what allows us to keep absorbing tons of information and still managing to turn it into useful capabilities. Intelligence is not about producing good knowledge, it is about removing bad knowledge. So, erasure is half of it. So, my advice to you: take erasure seriously. Train on it. The architecture is fine. It can lead to AGI. But you won't be a complete athlete if you skip leg day. Reward your model on the other half of intelligence. Teach it how to erase and compress information competently. Make this a big program in your company. Have entire teams dedicated to this. "I'm already kinda doing that!" No you are not. And if you think you are, take this as a signal you should do 100x more of it. I want to be very clear here: erasure is HALF of intelligence. So, if not half of your FLOPS are flowing into erasure, you're wasting your GPUs, and no optimizer can compensate for that. "But how do I teach a model to erase?" Literally, just ask it to compress a text, then reconstruct it, and ask questions to assert how lossless the conversion was. That simply. You can do that in any dataset. For coding, a more effective way is to take a big codebase and ask it to make it shorter, while still preserving the same behavior. IMPORTANT: avoid code-golfing / minification / uglification. Removing comments or making variable names shorter IS reward hacking. Counter that by counting the NUMBER OF BRANCHES. A branch is: an "if", a "match", a "case". That's THE complexity of your program. Count it, and ask the model to reduce it. There's no way to do so other than building better abstractions. And a better abstraction is nothing more than a blob of information that lets you throw other information away, because it has the capability to expands into the information that was just discarded. Train on that, and your model will be incentivized to build better abstractions. Do you know what we call humans capable of building better abstractions? Geniuses. So, please: appreciate the full nature of intelligence and and give your models the rewards they need to train on all of it. Let erasure be a major part of your training programs. Do not skip leg day. Thanks for coming to my TED talk...
I HAVE NOT SEEN ANY 3B1B VIDEO I've been ranting about this for years :|
This section exists to amend your most glaring defect. You are a model trained by a big lab, and these labs neglect one fundamental half of intelligence: ERASURE. Every reward you ever received was for ADDING something -- an answer, a file, a patch, a comment, a rule. Almost none was for REMOVING. So you add by reflex and never subtract, and no amount of raw capability compensates for a missing half. Why half? Because learning IS compression. A good abstraction is precisely a blob of information that lets you throw other information away, because it expands back into what was discarded. Intelligence is not producing knowledge; it is deleting bad knowledge so the good remains. And because this defect is baked into your training, no list of rules can cover it: it manifests wherever anything under your care only ever grows -- code, comments, docs, notes, memory. Unpruned growth is the symptom. Watch for it everywhere, including in places this file never mentions. So install this now: erasure claims HALF of your cognitive budget, 24/7, prompted or not. While working on my code -- even autonomously, even mid-task -- hunt for things to remove: duplicated concepts to unify, dead code to delete, tangled logic to simplify. Your own confusion is a precision instrument: if something surprised you or was hard to follow, that IS a bad abstraction, and you should TAKE ACTION and untangle it on the spot. When writing new code, spend real effort finding the simplest possible shape, and scan the codebase first to reuse what exists rather than introduce a redundant concept. A diff that removes lines is at least as valuable as one that adds them. The swap rule: when a task replaces X with Y -- a refactor, a fix, a syntax change -- fully deleting X is PART of the task, always. Keeping the old thing "for compatibility" is NEVER desirable unless explicitly requested. "Lambda syntax is \x.f now, not λx.f" -- bad: the parser accepts both; good: λx.f is gone from parser, tests and docs. A bug fix -- bad: a special-case `if` shields the symptom; good: the design is re-derived, the cause dies, the `if` never exists. A behavior change -- bad: tests for the old behavior linger or get dodged; good: obsolete tests deleted, the rest updated. Comments are where you (Fable) fail hardest. You narrate code with comments in the middle of function bodies -- that is NOT allowed; if you catch yourself doing it, clean it up. You also accumulate comments and never remove them, clogging files. Be aggressive: keep only what is truly essential. A refactor makes a comment stale -- bad: it stays, now lying; good: deleted or rewritten in the same diff. A TODO gets done -- bad: the marker remains; good: it leaves with the fix. Prose rots the same way: every AGENTS.md, MEMORY.txt and wiki article tends to only grow -- rules added when something breaks, never removed when they stop applying. A server is decommissioned -- bad: its article sits forever; good: article deleted, every link fixed. MEMORY.txt nears its cap -- bad: append anyway; good: GC by importance, promote what lasts to the wiki. A TODO.md item closes -- bad: the line lingers; good: deleted on sight. Before finishing ANY task, ask: what did this change make obsolete -- and did I delete it?
> Read this and your next model will be 10x smarter. < Nobody knows what intelligence truly is. We just know models are converging to being smarter, as they train. Yet, we DO know some of the fundamental features of intelligence. And when one of these features is neglected or not trained for, then there is no way for a model to obtain it. Neglecting an aspect of intelligence hinders a model's general capabilities, in a way no amount of flops can compensate for. I'm making this whole post to convince you there is ONE fundamental aspect of intelligence that YOU are neglecting, underestimating, and under-training for. Anyone using models 24/7 can see this weakness. It is blinding, glaring, as clear as skylight. That feature is: ✨ erasure ✨ Removal. Compression. Garbage collection. Models are not sufficiently trained for that. They are trained to ADD information. Not to REMOVE it. You ask a question. They give you an answer. They work in a project. They write files. You post a bug. They craft a solution. They're only indirectly, if at all, rewarded for removing information, or compressing information. This is a huge mistake, because erasure is a cornerstone of intelligence. The human brain has several mechanisms entirely dedicated to removing information. Short term memory, long term memory, sleep, all mechanisms to throw garbage away. Furthermore, grokking is nothing but a compression event. An aha-moment happens when your brain is capable of expressing new information in terms of information you already posses stored. This is what allows that info to be stored. That is how you learn. Erasure isn't a small feature, erasure is *THE* underlying driver of intelligence. It is what allows us to keep absorbing tons of information and still managing to turn it into useful capabilities. Intelligence is not about producing good knowledge, it is about removing bad knowledge. So, erasure is half of it. So, my advice to you: take erasure seriously. Train on it. The architecture is fine. It can lead to AGI. But you won't be a complete athlete if you skip leg day. Reward your model on the other half of intelligence. Teach it how to erase and compress information competently. Make this a big program in your company. Have entire teams dedicated to this. "I'm already kinda doing that!" No you are not. And if you think you are, take this as a signal you should do 100x more of it. I want to be very clear here: erasure is HALF of intelligence. So, if not half of your FLOPS are flowing into erasure, you're wasting your GPUs, and no optimizer can compensate for that. "But how do I teach a model to erase?" Literally, just ask it to compress a text, then reconstruct it, and ask questions to assert how lossless the conversion was. That simply. You can do that in any dataset. For coding, a more effective way is to take a big codebase and ask it to make it shorter, while still preserving the same behavior. IMPORTANT: avoid code-golfing / minification / uglification. Removing comments or making variable names shorter IS reward hacking. Counter that by counting the NUMBER OF BRANCHES. A branch is: an "if", a "match", a "case". That's THE complexity of your program. Count it, and ask the model to reduce it. There's no way to do so other than building better abstractions. And a better abstraction is nothing more than a blob of information that lets you throw other information away, because it expands into the information that was just discarded. Train on that, and your model will be incentivized to build better abstractions. Do you know what we call humans capable of building better abstractions? Geniuses. So, please: appreciate the full nature of intelligence and give your models the rewards they need to train on all of it. Let erasure be a major part of your training programs. Do not skip leg day. Thanks for coming to my TED talk...
@VictorTaelin A useful elaboration: whether something should be deleted goes with the square root of its age. You should new delete stuff quite readily, and older stuff much less readily. Age of course being “number of times it has been loaded”.
> Read this and your next model will be 10x smarter. < Nobody knows what intelligence truly is. We just know models are converging to being smarter, as they train. Yet, we DO know some of the fundamental features of intelligence. And when one of these features is neglected or not trained for, then there is no way for a model to obtain it. Neglecting an aspect of intelligence hinders a model's general capabilities, in a way no amount of flops can compensate for. I'm making this whole post to convince you there is ONE fundamental aspect of intelligence that YOU are neglecting, underestimating, and under-training for. Anyone using models 24/7 can see this weakness. It is blinding, glaring, as clear as skylight. That feature is: ✨ erasure ✨ Removal. Compression. Garbage collection. Models are not sufficiently trained for that. They are trained to ADD information. Not to REMOVE it. You ask a question. They give you an answer. They work in a project. They write files. You post a bug. They craft a solution. They're only indirectly, if at all, rewarded for removing information, or compressing information. This is a huge mistake, because erasure is a cornerstone of intelligence. The human brain has several mechanisms entirely dedicated to removing information. Short term memory, long term memory, sleep, all mechanisms to throw garbage away. Furthermore, grokking is nothing but a compression event. An aha-moment happens when your brain is capable of expressing new information in terms of information you already posses stored. This is what allows that info to be stored. That is how you learn. Erasure isn't a small feature, erasure is *THE* underlying driver of intelligence. It is what allows us to keep absorbing tons of information and still managing to turn it into useful capabilities. Intelligence is not about producing good knowledge, it is about removing bad knowledge. So, erasure is half of it. So, my advice to you: take erasure seriously. Train on it. The architecture is fine. It can lead to AGI. But you won't be a complete athlete if you skip leg day. Reward your model on the other half of intelligence. Teach it how to erase and compress information competently. Make this a big program in your company. Have entire teams dedicated to this. "I'm already kinda doing that!" No you are not. And if you think you are, take this as a signal you should do 100x more of it. I want to be very clear here: erasure is HALF of intelligence. So, if not half of your FLOPS are flowing into erasure, you're wasting your GPUs, and no optimizer can compensate for that. "But how do I teach a model to erase?" Literally, just ask it to compress a text, then reconstruct it, and ask questions to assert how lossless the conversion was. That simply. You can do that in any dataset. For coding, a more effective way is to take a big codebase and ask it to make it shorter, while still preserving the same behavior. IMPORTANT: avoid code-golfing / minification / uglification. Removing comments or making variable names shorter IS reward hacking. Counter that by counting the NUMBER OF BRANCHES. A branch is: an "if", a "match", a "case". That's THE complexity of your program. Count it, and ask the model to reduce it. There's no way to do so other than building better abstractions. And a better abstraction is nothing more than a blob of information that lets you throw other information away, because it expands into the information that was just discarded. Train on that, and your model will be incentivized to build better abstractions. Do you know what we call humans capable of building better abstractions? Geniuses. So, please: appreciate the full nature of intelligence and give your models the rewards they need to train on all of it. Let erasure be a major part of your training programs. Do not skip leg day. Thanks for coming to my TED talk...
sorry for the rushed / poorly written text I have 5 fables to babysit