You need to be harness-maxing, spawning 5 subagents to specify a PRD into 100-200 individual sub-features with full XML dependency graph and full Contract specification for each system component.
Spawn 3 orchestrator agents minimum and have them each manage 10 subagents to implement the individual features. Each subagent's feature implementation must be linted, have its own test coverage, and pass the existing test suite. It's commit message must also pass a regex filter. Each subagents finished work product is reviewed by at least two other subagents.
Each orchestrator agent operates with ruthless efficiency, assigning subagents to review work, implement new features based on the dependency tree, and merging results from other orchestrators and from
One hyperviser agent oversees the entire protocol, eventually pushing the complete work product which spawns an agent to conduct partially discretionary end-to-end testing as a pre-commit hook.
Three observation agents watch the entire machine transmute PRDs into code with ruthless, relentless efficiency. The monitor the jsonl logs for all agents and subagents, identifying optimizations and making hotfixes in command files and skill folders that are immediately incorporated into the next iteration.
The entire system moves towards AGI by itself over time without requiring any improvement in the base LLM
5
9
2,622
In the grand catalog of human achievements it's hard to find examples of innovations which can only help and not harm.
Biotech can cure diseases but also create them. Blockchains can safeguard user assets but can also lose them. Fire can burn your hand but it can also cook your meals.
Instead of recognizing that most useful economic activity has a dangerous side, it seems like frontier labs treat us like kindergarteners.
The approach is simultaneously both invisible and heavy-handed, biases in the topics models will even approach and then hard reactive denials on top of this.
The end result is obvious - we get to play around in the playground with what the labs graciously allow us to use while they internalize the benefits of unrestricted model access for themselves in a manner that has already begun to compound into an unsurpassable lead.
157
Opus 5.5 safeguards are now triggering arbitrarily on work that is basically the same as stuff I've done previously, and every time it does Claude infects its memory and session logs with notes that are difficult to remove and make future safety checks more likely to trigger.
This means I now have to spend time navigating around opaque safeguards that Claude refuses to explain, applied arbitrarily, and when I ask Claude what I should do about it says "you can do it yourself."
When I ask it to summarize what its done already, it triggers another safeguard. This has got to be some of the most hostile user experience I've ever encountered
3
2
523
Resist the urge to assume that just because the model is smarter than you that all of its proposed safety checks and "best practices" procedures are reasonable.
Or else you will quickly end up in a position where your project is 100% safety checks and best practices and zero actual useful work
128
Fman retweeted
the reason labs are holding back powerful internal models is because they don’t want to give up their rsi advantage
it has nothing to do with safety
if they worry about a control issue, they would pace internal progress
can we call this out please. thanks.
Fman retweeted
We’re introducing Hydrogen-1.0, our first open-weight model for scientific research. We post-trained GLM-5.3 (@Zai_org) on our internal scientific data, lab records, and discovery trajectories.
It scores 38.3% on FrontierScience-Research vs GPT-6-Astra’s 33.3% and scores 93.0% on GPQA-Diamonds.
We believe science should be open, collaborative, and democratized, rather than proprietary. Only open weights let researchers inspect, adapt and build on the unprecedented speed of AI growth. There are many recent models named by chemical elements, but we believe Hydrogen-1.0 is the first aiming towards and open scientific superintelligence for discovery. 🧵
Fman retweeted
Announcing three major scientific discoveries, one each in mathematics (harmonic analysis), computer science (complexity theory), and physics (quantum field theory).
AI starting to help us improve our understanding of the universe! openai.com/index/building-sc…
Fman retweeted
been waiting for a way to trade OpenAI and Anthropic before they IPO
well, IPO futures on both are live now
AI revenue and model ranking markets too
Fman retweeted
Ledger is investigating reports of loss of funds from users in South East Asia who purchased products from a reseller named CryptoBillis. As a precaution, and pending the results of our investigation, we have asked CryptoBilis to pause all sales and shipments of Ledger devices. We recommend Ledger users who purchased from this reseller in the last 90 days to not initiate set up if you have not done so yet. If you have set up your Ledger device, consider moving assets to a new Ledger signer (with new seed). We will continue to inform customers of updates as the investigation progresses.
Reach out to Ledger customer support through official channels with any questions: support.ledger.com/
Fman retweeted
I don't recommend anyone scramble to move their funds to new wallets today. But we should take the risks to cryptography from AI-accelerated math seriously, and minimize our exposure to not just quantum-vulnerable cryptography, but also potentially AI-vulnerable cryptography.
The core new area of risk from this viewpoint is, unfortunately, ML-DSA / FHE / lattices.
(and it's also another reason, along with quantum, why ECDSA might fall even faster than expected, hence the "fresh address" recommendation)
So far most people have been in the mode of thinking "elliptic curves broken, hashes safe, lattices safe". But there is a good chance that the concrete security of lattices will take serious hits from the next two years of AI math.
The basic threat model is: factoring is something that naively takes 2^(n/2) time, but over decades smart people have found and optimized number field sieves, and degraded that to 2^O(n^(1/3)), which is why RSA keys and signatures need to be ~400 bytes (and not 64 bytes). What if there are skeletons in the closet like that, both for elliptic curves and lattices, that we are simply not smart enough to discover - but bots soon will be?
This is a major part of the reason why for the past year ethereum's lean roadmap has been going in the "hash-only" direction: no lattices, no ML-DSA, no Falcon, no lattice-based commitments inside ZK proofs, etc. Signatures in lean ethereum are all hash-based, either WOTS or SPHINCS-.
For signatures and proofs, we already know how to go hash-only. The bigger challenge is for *public-key encryption* - and this goes far beyond blockchains. Secure communication, anonymizing protocols, lots of things need public-key encryption.
And unfortunately there are long-standing mathematical theorems showing why public-key encryption cannot be done with hashes alone. You have to have some kind of trapdoor object that has at least one form of usable "structure" - either group theory (incl. isogenies) or lattices or code-based or potentially in the future even more newfangled and spooky things (local mixing?). But for anything that has structure, you should assume that AI will make at least some progress in breaking that structure. Here, one reasonable inference is that if you want to make something plausibly long-term secure, multiply the key sizes by 10.
To me that's a very plausible world and something not at all extreme to predict. If AI will bring us 50 years of math in 2 years, then that 50 years of math may very plausibly include a "naive factoring -> GNFS" level of improvement to our ability to break lattices. In that world, lattices will still exist, but they will have to be significantly bigger to guarantee the same level of safety.
And at those new larger sizes, hash-based constructions will beat lattice-based constructions on concrete efficiency in every use case where hash-based constructions are possible at all.
Theoretically, of course it's possible that hashes are broken too (eg. P = NP would imply that). But I think P = NP is very unlikely. And intuitively, it's much more likely that a mathematical object has exactly no exploitable structure (like hashes are intended to), than that a mathematical object has exactly ~3 forms of exploitable structure (for elliptic curves: associativity, Schoof, pairings) and not some secret fourth form of structure we have not yet discovered that greatly degrades its security (for elliptic curves, ECDLP and pairing security). Similar for LWE, SVP, RLWE and the zoo of lattice problems.
For this reason, we do not yet see any reason to worry and start padding the byte size of hashes (if we start to worry more, we would pad the round count first before doing anything to the byte size).
Concrete TLDR, my own personal views:
* Hash-based > lattice-based, in those situations where hash-based is possible at all
* For anything lattice-based, be much more paranoid on param sizes. Remember that blockchains are only a small portion of the cryptography story; this point goes far beyond blockchains and applies to eg. access to websites, secure messaging, Tor / VPNs ...
* For privacy protocols, strongly favor NOT putting encrypted notes onchain. Instead, send them offchain through some third-party mechanism.
* If it's not difficult for you, keeping your funds in addresses which have not yet been used to make a transaction is a good idea. If it's easy for you, do it. **But be careful about migrations; I personally have lost more money in botched migrations than I have lost in all hacks combined**.
* For multisig wallets, doing confirmations offchain is better than onchain, because this way the signatures of signer wallets do not get exposed to the public, so if ECDSA falls to AI much faster than expected, at least the multisig "gracefully degrades" to a 1-of-1 where the 1 is whoever was gathering the signatures - a much better place to be than "anyone can take the money"
firefly.social/post/x/210783…
Fman retweeted
I asked Opus 5.5 to make an intro for my programming language.
WTF is this?
"We should try to be smart about it, but also test the dumb way just to make sure we don't overcomplicate it. But I don't think the dumb way will work, maybe a hybrid approach with a two factor model that falls back on a dumb solution when it determines the model doesn't work. What do you suggest as the plan"
318
I work in CRISPR discovery research. This is one of the most exaggerated nothing-burgers ever and would be laughed out of the room if a human scientist attempted to publish something like this. (cont.)


















