Very curious how it works for those who have never been able to see. A true success in perceptual field expansion would be an amazing achievement
This is a great survey on formal verification tools (language focused) for those interested in getting started.
Okay, let's do this.
Isabelle, Lean, and Rocq (formerly Coq*) are theorem provers. They are meant to prove mathematical theorems. We use them for formal verification by either 1) translating a program to the theorem prover (risking a translation error) or 2) using a language built into the theorem prover that extracts into a working binary.
Fizzbee, TLA+, Spin, Alloy, Quint, and P are specification languages. They are meant for checking high-level blueprints of programs. After checking the blueprint, you still need to make sure your program matches it, which is a hard problem.
Specification languages differ in what they make easy to express. P, Spin, and Fizzbee are designed to be closer to the code implementations. P looks like interacting state machines, Spin looks like C with CSP, Fizzbee looks like a dialect of Python. It's easier to use a codelike specification language and refine it to code, but you can't do as much with it.
Alloy, TLA+, and Quint are more abstract. Alloy looks like a bunch of algebraic relationships, TLA+ is a much of logical formula, and Quint is a programmer-oriented (and statically typed) condensation of TLA+. Abstract modeling languages are harder to get started with and harder to represent things, but you can represent a wider class of systems with them.
I believe UPPAAL is a specification language for realtime systems. This is a field I have no experience in. It seems a graphical language, though, which would make LLM-assistance difficult.
Dafny is a verifiable programming language. It has regular programming language features, but also a bunch of features to express and prove properties of the program. It uses SMT solvers to actually prove the properties, meaning you don't need to learn a proof language (though you need to learn to cajole the solver). Dafny is probably the easiest thing on your list to get started with, but also the least likely to meet any weirder needs you might have.
I don't know what Ivy is but some cursory Kagiing suggests it falls in the specification language category.
Some other things @spin_lock_init didn't mention:
- Other theorem provers: Agda, Metamath
- Other abstract specification languages: mcrl2, NuXMV, Event-B
- Other verifiable programming languages: Idris, F*, Whiley
- There's also using a verifiable subset of a language, like Verus for Rust or SPARK for Ada.
So, what you need to pick depends on what you want to do.
You'll get the maximum power with a theorem prover. Lean is the de facto language for vibeproving, but Anthropic recently published a post about vibeproving in Rocq so YMMV.
If you want to make abstract models of software systems, go for a specification language. Which you choose depends on a lot of factors. If your system can be represented as lots of simple communicating state machines over a network, try P. Spin, I believe, is close to simple C/Go with a network and channels. I have never used Fizzbee.
Alloy is good for domain modeling, but struggles with really complicated temporal actions, nested data structures, and largish numbers. Also AIs aren't to good at it (last I checked, in March). Runs fast and makes good visualizations though.
TLA+ and Quint are for modeling complex temporal systems. I'm partial to TLA+ but know a lot of people who say Quint is easier to get into.
Note P, Fizzbee, and Quint all claim to have features for testing a codebase against a spec. I can't vouch for any of them, though. None of the languages I mentioned (except maybe NuXMV?) are particularly good at modeling sequential, deterministic algorithms.
Use Dafny if you need to just write a verified program and don't care which language it's in. I don't think other verifiable programming languages are as user-friendly for the time being. Consider a verified subset if you already know a language and want to just augment it with more correctness.
You may need other, more exotic tools depending on your particular needs. Regardless of the above advice, don't be afraid to use the wrong tool for the job. If you vibe well with a language, and you achieve good LLM-sympathy with it, you'll be able to go farther than using a "right tool" you don't like.
This seems pretty important
A deterministic, unconditional algorithm that lists the primes below N in N (log log N)^{1+o(1)} bit operations on a multitape Turing machine, using GPT-6 Astra, building upon Harvey's recent breakthrough on prime enumeration. This achieves the bound from his paper without needing its conjecture.
(1/n)
Getting access to logs (operational data) and getting access to customer content (customer data) are not the same thing.
This needs investigating, but if the screenshots I am seeing are the whole thing, this is likely a nothingburger.
Source: I worked for Microsoft, I worked specifically on doing data cataloguing and removal from logs of Customer Data during the big GDPR-worldwide push for MSR data and Decision Service data.
Unless the GCC Geneva Logs somehow log actual customer data (bad!), the compliance rules do not appear to have been violated.
🚨BREAKING (EXCLUSIVE): National Security Concerns Leaked by MSFT Whistleblower
Leaked Microsoft screenshots show an India-based engineer received approval to view U.S. government cloud logs.
A Microsoft whistleblower contacted me and shared screenshots supporting allegations that Microsoft used its “escort” process to allow an India based engineer to access Government Community Cloud (GCC) systems. The whistleblower alleges the engineer is not a U.S. citizen.
Microsoft’s own published rules state that temporary elevated access to customer content in GCC requires verified U.S. citizenship. The escort model is the workaround the company uses so non-U.S. personnel can still direct the work.
The screenshots show Viraj Chokhany requesting and receiving approval for escort access to view logs in the DPRODMGD151 environment, which is part of Government Community Cloud Moderate — the cloud used by many federal, state, and local agencies.
In the escort process, a U.S. person is supposed to open the system while the India-based engineer guides the work.
The whistleblower believes this raises urgent national security concerns and may violate FedRAMP requirements.
Multiple Microsoft employees have reviewed the screenshots and confirmed they appear authentic. Viraj, has been confirmed to live in India-- Where he also attended and graduated college.
The whistleblower is working on a public statement. I will release the whistleblowers statement when I receive it.
Attached images are some of the screenshots that I received from the Whistleblower.
@DHSgov @FBIDirectorKash @JDVance
Jacob Alber ️ retweeted
Has anyone considered using 4️⃣ as their private key? In unicode it's 7 bytes (56 bits).
This feels like a fair compromise between the two main stakeholder positions, "Private keys should be at least a little bit secure" vs "I want my private key to be 4"
Time to change passwords? Time to #PasswordShame.
Today's contestant is @venmo:
Venmo, why do you forbid any "special" characters other than ~@#%*(^&+=?
What did the humble minus sign (-) do to you?
If the AI labs keep playing these stupid games they are going to get regulated and not in the way that they want to be
This is dumb when it is only social media. Not being presented with the actual violation at hand, then a completely opaque (likely automated and possibly just fictional) appeal process when it is access to economic capability at this scale is beyond the pale.
Replying to @Hancock44043518 @OpenAI
Zero explanation. This is the first mail I received. I appealed, and they denied the appeal.
Dear Software Industry. The following XCKD was not meant to be a guide on how to do it.
Thank you for coming to my TED talk.
Getting hit with not-mine login attempt on an M365 account every 10-20 minutes
@Office - please advise
We are inventing Agent Workflows from first principles.
Boris Cherny, Head of Claude Code at Anthropic, just shared an official tip before Fable 5.5 ships
The setup: split your workload across Opus 5.5, Sonnet 5.5, and Haiku 5.5, and let them talk directly across your open terminals
Zero context pollution between windows: independent sessions ping each other via plain-text IPC over local sockets without burning a single token on conversation history
You just launch Claude Code like this:
claude --model sonnet --settings '{"crossSessionInbound":"accept"}'
here's the split:
→ Opus 5.5 architects session permissions: audits ListAgents discovery, enforces inbound message policies, and signs off on multi-terminal diffs
→ Sonnet 5.5 executes code fixes: builds endpoints, updates schemas, and patches dependent code whenever a peer session reports a breaking change
→ Haiku 5.5 relays inter-session messages: processes SendMessage pings across terminals at 340 tok/s with zero history bloat and sub-millisecond local socket latency
→ you stop burning Opus context on manual copy-pasting between terminals and keep your sessions lean
Opus only steps in at three moments:
→ setting up cross-session topology and inbound security rules before launch
→ evaluating contract diffs when a peer message signals an API schema update
→ signing off on synchronized multi-session PRs before merging to main
Opus architects · Haiku relays · Sonnet executes
JEV engineering is the same move one layer down: the forks that need no thinker (which peer, which tool, forward or drop) go to JEV in milliseconds, and the big models only see the ones that split
the full tree
> Opus 5.5 architects session permissions and audits cross-session topology
> Haiku 5.5 relays SendMessage pings between terminals at 340 tok/s
> Sonnet 5.5 patches code across workspaces when a peer signals a change
> Sessions discover each other automatically via ListAgents and /peers
> Messages travel as isolated plain text over local IPC sockets with 0 context dump
> JEV routes micro-forks in milliseconds
paste the tree and this prompt into Claude Code ↓
"Rebuild my Claude Code setup around this tree:
1. Configure cross-session discovery using /peers and set crossSessionInbound to accept
2. Delegate all peer-to-peer message routing and notification triage to Haiku 5.5 at 340 tok/s
3. Spawn Sonnet 5.5 to execute code edits and synchronize types whenever a peer session reports an update
4. Restrict all cross-session payload traffic to lightweight plain text via SendMessage with zero history transfer
5. Reserve Opus 5.5 for inter-session capability authorization and final sign-off before committing
Show me every change as a diff first. No edits until I say go"
↳ code.claude.com/docs/en/cros…
bookmark this, your terminals now talk to each other
> We are just predicting the next most logical sequence of words based on the context of the words right before it.
I do not believe this claim is justified by the paper in question. People really need to stop jumping the gun with LLM analogies.
Chomsky was wrong.
Researchers found your brain doesn’t store language the way every textbook since 1957 claims.
For decades, the undisputed rule of linguistics, led by Noam Chomsky, was that human language is hierarchical.
We were told our brains process language using complex "grammar trees." That we secretly build deep, abstract, mathematical rules in our heads before we speak.
This new paper proves that is completely wrong.
Researchers at Cornell University analyzed how people actually process and produce language in real time.
They found sequences. Linear chunks.
When we speak, we aren't calculating deep syntactic rules. We are just predicting the next most logical sequence of words based on the context of the words right before it.
We string linear chunks together.
If this sounds familiar, it should.
This is exactly how Large Language Models like ChatGPT work.
For years, critics have dismissed AI as "just a next-token predictor." They said it isn't truly intelligent because it doesn't understand deep grammatical hierarchies like humans do.
But this paper suggests humans don't use those hierarchies either.
We are just predicting the next chunk.
Language isn't a rigid tree of mathematical rules. It's a linear stream of contextual predictions.
We thought we were building AI to mimic the complexity of the human brain.
It turns out, the human brain was just running a simpler algorithm all along.
People who are not programmers need to stop gatekeeping programmers' use of AI. This applies particularly strongly to the games industry.
I'm not sure a lot of people understand what game coders actually do. We're not spending 9 hours a day finely hand crafting artisan software and expressing our inner dreams... 90% of the time we are fighting compilers and existing architecture, having to work out how undocumented code works, and tracking down obscure bugs and behavioural issues.
Most of game programming is just difficult, tedious, laborious grunt work, and the cognitive load we have to endure to get anything done is tiring and frustrating. No game coder is doing it for this 90% of the job.
We make games because the 10% that IS actually about making things fun and expressing ourselves is so incredibly rewarding it makes the other 90% bearable.
Now imagine if there was a tool, some kind of AI agent maybe, which could do most of the 90% grunt work for you, leaving you to just make all the decisions and express your creativity. How amazing would that be. How completely revolutionary would that be.
> Why would billionaires permanently leave California in response to a one-time tax
Because they have learned from history.
Replying to @gabriel_zucman
The key problem is this:
Why would billionaires permanently leave California in response to a one-time tax owed if they lived there on January 1, 2026?
It would only make sense for them to leave if the tax becomes annual.
But if the tax becomes annual, it would also generate revenue annually — by virtue of, well, being annual.
There are only two kinds of companies in the world: Those who have been hacked and those who don’t know they’ve been hacked




















