There is a certain genre of argument against Bitcoin that has become so familiar, so ritualized, and so gloriously unintentionally funny that it deserves to be studied as a literary form. At the center of this art stands Peter Schiff, tireless gold evangelist, professional Bitcoin scold, and perhaps the greatest accidental critic of the entire digital age.

Schiff’s case against Bitcoin often goes something like this:

• You can’t eat it.

• You can’t do anything with it.

• It has no intrinsic value.

• It’s just code.

• It’s not real.

• It only has value because people believe it does.

• It has no long history.

• It wastes energy.

• It’s speculative and volatile.

At first glance, these sound like objections to Bitcoin. But with only a tiny bit of effort, one discovers that these are not really arguments against Bitcoin at all. They are arguments against the internet, software, digital networks, modern finance, intellectual property, cloud computing, and possibly the concept of civilization after 1995.

Well, this is awkward. Let’s destroy each and every one of these points and collectively laugh at them.

This Substack is reader-supported. To receive new posts and support my work, consider becoming a free or paid subscriber.

You can’t eat it

A devastating point. Truly. You also cannot eat:

• the internet

• email

• a spreadsheet

• a domain name

• an operating system

• a search engine

• a video call

• a stock certificate

• a software license

• an API

And yet millions of people somehow continue to derive value from these things without frying them in butter.

The “you can’t eat it” test is a wonderful standard because it instantly eliminates most of the modern economy. You cannot eat Adobe Photoshop. You cannot eat AWS. You cannot eat a TCP/IP packet. You cannot eat a patent. You cannot eat a password manager. Therefore, by the Schiff Standard, these should all be worth approximately zero.

This is good to know. Somebody should inform the market.

You can’t do anything with it

This one is even better, because the internet is basically the grand cathedral of things you “can’t do anything with” until you notice that nearly everything runs on it.

What exactly can you do with the internet? Only trivial things, such as:

• communicate instantly across continents

• move information at near light speed

• run businesses

• publish books

• build software

• coordinate logistics

• stream media

• educate billions of people

• replace entire industries

• create global marketplaces

Other than that, not much.

The complaint that something digital “does nothing” usually means one of two things: either the speaker is ignoring its use entirely, or they are using an absurdly narrow definition of use that excludes communication, computation, settlement, coordination, and storage because those do not arrive in wheelbarrows.

It has no intrinsic value

The phrase “intrinsic value” has done remarkable service as a rhetorical fog machine. It sounds deep, ancient, and wise. It is also often used in a way that immediately collapses when applied to almost anything people actually value.

What is the intrinsic value of the internet?

Not the poetic answer. The literal one.

What is the intrinsic value of:

• a routing table

• a packet

• a DNS record

• a TLS certificate

• a Git commit

• a JPEG

• a database entry

Very little, in isolation. And yet in aggregate, these things coordinate economies, institutions, and daily life.

It turns out value can be emergent. A network can have value because people use it, rely on it, build on it, and cannot easily replace it. This is not some embarrassing loophole. This is how most important systems work.

If “intrinsic value” means “I can hold it in my hand and admire its atoms,” then yes, software is in trouble. So is language, law, mathematics, accounting, and your bank balance.

It’s just code

Yes. And?

The internet is just code. Your phone is code wrapped in aluminum. Your bank is code wearing a necktie. Air traffic systems are code. Hospitals are code. Power grids are code. Satellites are code plus confidence.

Calling something “just code” in 2026 is a bit like standing in the middle of Manhattan and declaring, with enormous seriousness, “These buildings are just piles of concrete and steel.”

Correct. That is how systems work.

“Just code” is one of those phrases that hopes the word “just” can do the work of an actual argument. It cannot. Code is not fake because it is abstract. Code is how abstraction takes operational form.

It’s not real

This is probably the crown jewel.

The internet is not real in the sense that a brick is real. Neither is a corporation, a trademark, a treaty, a debt obligation, a tax lien, a university degree, a brokerage account, or the number in your checking account.

And yet all of these can dramatically alter your life.

The modern world is built from layers of shared abstraction. Some are written on paper. Some are enforced by courts. Some are maintained by software. Some are maintained by consensus. Some are maintained by a server farm humming somewhere in a cold place.

“Not real” usually means “not physical,” which is a hilariously outdated standard in an economy where intangible assets routinely dominate tangible ones.

Try telling a software company its source code is “not real.” Then watch how real the lawyers become.

It only has value because people believe it does

At last, we arrive at the accidental self-own of self-owns.

Yes. Correct. That is how almost all large-scale human systems function.

Laws work because people believe they do. Brands have value because people believe they do. A college degree has value because people believe it does. A social network has value because people believe other people will continue to use it.

The internet itself is valuable because billions of people believe the protocols, standards, institutions, and services layered on top of it are worth depending on.

This is not a flaw. This is the basic operating system of society.

When critics say, “Bitcoin only has value because people believe in it,” they often seem to think they have uncovered a fatal weakness. In reality, they have rediscovered coordination.

It has no history

Neither did the internet once.

This is one of the all-time great arguments for being permanently late to everything.

In the early days, the internet had no long history. Neither did cars. Neither did airplanes. Neither did smartphones. Neither did streaming. Neither did cloud computing. Neither did the web itself, which many brilliant people once regarded as a toy, a fad, or a chaos machine for nerds.

If lack of history were a disqualifier, every important technology would die in infancy.

The best part of this argument is that it becomes less useful every year while being delivered with the exact same confidence. “It has no history” is a time-sensitive objection pretending to be timeless wisdom.

It wastes energy

A fascinating complaint to level against digital systems while standing waist-deep in the energy consumption of the modern world.

The internet uses enormous amounts of energy. Data centers use energy. Streaming uses energy. Cloud infrastructure uses energy. Search uses energy. Video calls use energy. AI definitely uses energy. Your thousandth open browser tab about sourdough hydration uses energy.

Energy use is not the same thing as waste. The question is whether the output justifies the input.

Civilization runs on converting energy into outcomes humans value. That is true for steel, shipping, refrigeration, semiconductor fabs, hospitals, server farms, and communications networks.

If “uses energy” is enough to dismiss a system, unplug everything and let us return honorably to yelling across valleys.

It’s speculative and volatile

The dot-com bubble would like a word.

The existence of speculation around a technology does not prove the technology is useless. It proves humans are humans. They overhype real things, fake things, semi-real things, and occasionally tulips. The presence of mania tells you exactly one thing: people are bad at pricing the future.

The internet absolutely had a speculative bubble. An enormous one. Many companies exploded. Many valuations were nonsense. Many investors got torched. And then, in a shocking development, the internet remained useful.

A bubble can form around nonsense. It can also form around a transformative innovation. These are not mutually exclusive.

A brief and helpful exercise

To save time, here is a simple test for future anti-Bitcoin arguments.

Take the argument and replace “Bitcoin” with:

• the internet

• software

• email

• cloud computing

• digital payments

• online banking

• domain names

• intellectual property

• social networks

If the argument suddenly makes you sound like a man angrily denouncing electricity from a candle shop, it may need work.

Examples:

“Email has no intrinsic value.”
“Cloud computing is just code.”
“Domain names only have value because people believe they do.”
“You can’t eat the internet.”
“Video calls have no history compared to gold.”
“Software wastes energy.”
“APIs are speculative.”

Wonderful. Amazing. Please continue. We are learning so much.

Why this matters

The point is not that Bitcoin and the internet are identical. They are not. The point is that a huge number of lazy anti-Bitcoin arguments are actually lazy anti-digital, anti-tech arguments. They rely on a primitive worldview in which only physical, immediately tangible, directly consumable things can possess durable value.

That worldview is not serious enough for the modern economy.

We live in a civilization where value is regularly created by networks, standards, code, consensus, legal abstractions, and information systems. If your framework cannot account for that, your framework does not get to smugly announce reality’s failure to comply.

It just means your map is old.

In conclusion: unplug everything

If we are to be consistent, we must act boldly.

If you cannot eat it, it is worthless. If it is code, it is fake. If it depends on belief, it is fraud. If it lacks centuries of history, it is unserious. If it uses energy, it is evil. If it is volatile, it is doomed.

Therefore we must immediately abandon:

• the internet

• software companies

• online commerce

• remote work

• streaming media

• cloud infrastructure

• electronic records

• most of finance

• and perhaps language itself, since it too is a consensus system with no intrinsic value beyond human belief

At long last, Peter Schiff has shown us the way.

Not merely beyond Bitcoin.

Beyond the internet.

Beyond modernity.

And all the way back to the comforting solidity of a shiny rock.

We hold these truths to be self-evident: that all People are entitled to life, liberty, and the pursuit of happiness; that governments derive their just authority from the consent of the governed; and that when leaders betray that trust through corruption, intimidation, or indifference to justice, it is the right and the duty of The People to protest, to expose wrongdoing, and to demand accountability.

The history of Donald J. Trump, is a history of grievances against the principles of a free republic.

He has treated public office as a stage for personal power rather than public service.

He has attacked courts, elections, journalists, and institutions whenever they threaten his authority.

He has blurred the line between the wealth of the nation and the wealth of himself and his allies.

He has divided citizens against one another so that loyalty to a leader may replace loyalty to the Constitution.

He has mocked and dismissed accountability when confronted with scandal.

He has presided over growing controversy surrounding the Epstein files, where powerful figures and networks of influence have been shielded by secrecy, redactions, and delay—leaving the public to question whether justice is equally applied to the powerful and the powerless.

He has also led the nation into recent military attacks on Iran without clear congressional authorization, sparking intense debate about war powers and the legality of unilateral military action. Such strikes violate both constitutional limits and international law, while the resulting escalation has already produced thousands of casualties and deepened instability across the region.

These actions, form a pattern: shielding the powerful, obscuring the truth, and risking the lives and liberties of The People for the ambitions of a few.

A prudent People do not cast off their government lightly; when a leader repeatedly places personal power above the rights and dignity of the nation, it becomes the duty of citizens to speak plainly.

Therefore we declare not our separation from our country—but our renewed independence from corruption, secrecy, and the rule of any single man.

And for the support of this declaration, with firm reliance on the principles of liberty and justice, we pledge our voices, our vigilance, and our refusal to forget that in a republic The People—not the ruler—are sovereign.

That engine is people, code, tooling, shared context, and the invisible web of decisions that make tomorrow easier than today. When a company does layoffs, it is not just shrinking payroll. It is changing the shape of the engine. And in early 2026, a lot of companies are doing it at the exact moment when the engine is about to get materially stronger. I’m looking at you, Block.

The reason is simple: revenue per employee in big tech is already massive, and the next wave of AI assistance is set up to push that number higher. At the same time, the cost of AI capability keeps dropping, which turns “more output per engineer” from a nice idea into a default competitive condition. Stanford HAI’s 2025 AI Index reports that the inference cost for a system performing at the level of GPT-3.5 dropped over 280-fold from November 2022 to October 2024. (Stanford HAI) And these numbers will just keep improving for the foreseeable future. See Ray Kurzweil’s Law of Accelerating Returns.

If you accept that trend, even cautiously, then layoffs aimed at “efficiency” start to look like a misread of what efficiency is about to become.

A metric that forces the conversation to stay honest

If you want to argue about layoffs without turning it into vibes, pick a blunt metric: revenue per employee (RPE).

RPE tells you, at a high level, how much revenue the organization generates per person. When RPE is already in the seven figures and rising, the default stance should be: the company has leverage, and the question becomes how to deploy it without damaging compounding capacity.

Below are recent RPE figures for major tech companies, sorted in ascending order, using their reported revenue and reported employee counts. These numbers are rounded.

• Amazon: company-wide RPE is roughly $0.41M in 2024, using $637.959B of consolidated net sales and ~1.556M employees. This understates the leverage of software-heavy parts of the company because Amazon’s workforce includes a massive frontline logistics and delivery operation. (SEC)

• Microsoft: roughly $1.24M in FY2025, using $281.7B of revenue and ~228k employees. (Microsoft)

• Alphabet: roughly $1.91M in 2024, using $350.018B of total revenues and ~183k employees. (Q4 Capital)

• Meta Platforms: roughly $2.22M in 2024, using $164.501B of total revenue and ~74,067 employees. (SEC)

• Block: pre-layoffs (I will discuss post-layoff numbers later in this article):roughly $2.37M in 2025, using $24.194B of total net revenue and 10,205 full-time employees. (StockTitan).

• Apple: roughly $2.38M in FY2024, using $391.035B of total net sales and ~164k employees. (SEC)

• Nvidia: roughly $3.63M in FY2025, using $130.5B of revenue and ~36k employees. (SEC)

Those numbers are not “normal corporate performance.” They are the signature of software leverage and platform economics at scale.

Now add AI.

AI pushes RPE up, and it pushes “need more engineers” up right alongside it

There is a lazy version of the AI narrative: buy AI tools, cut headcount, declare victory.

The better model is: AI raises the ceiling on what a strong engineer can do, then competition forces companies to chase that ceiling.

Stanford’s AI Index gives a clean, visceral example of why the ceiling rises. When the cost of querying models at GPT-3.5 quality drops by more than 280× in under two years, adoption stops being a debate and starts being a default. (Stanford HAI)

Here is the key consequence that companies keep missing:

If revenue per engineer rises, demand for engineers rises too.

Why? Because the ROI on engineering rises. The same company that used to need 10 engineer-months to ship a feature might now do it in 6. That does not mean it should hire fewer engineers. It often means it can profitably ship more features, integrate faster, localize more markets, reduce support load, tighten security, and build entirely new product lines. The constraint becomes “how many capable people can we put on this and still move fast without breaking things.”

This is exactly how labor costs climb: the value per engineer goes up, and companies compete for the same pool of high-signal talent.

You can see the demand side in plain official terms. U.S. Bureau of Labor Statistics projects employment for software developers, QA analysts, and testers to grow 15% from 2024 to 2034, with about 129,200 openings per year on average. (Bureau of Labor Statistics)

The “hire now” incentive that smart companies will act on

There is a quiet incentive here that is easy to miss if you only look at next quarter’s expenses.

If engineering labor costs are about to inflate, then the smart companies have a reason to hire earlier, not later.

They are not just hiring to ship features. They are hiring to lock in a cost basis.

You can think of it like buying long-duration capacity before the price reprices. A company that builds a dense bench of strong engineers now can grow into that capacity while market wages and equity packages become more aggressive. A company that waits will be hiring into a world where:

• productivity per engineer is higher,

• revenue per engineer is higher,

• and therefore the bidding war for top engineers is worse.

We already have a very loud signal of where this goes in the frontier AI world. The Wall Street Journal reported that OpenAI’s stock-based compensation averaged about $1.5 million per employee across a workforce of roughly 4,000 in 2025. (The Wall Street Journal) That is the cost of being early in a talent market where a small number of people can move a very large revenue number.

And importantly, this does not stay contained inside frontier AI labs. It leaks outward. Every big company trying to “do AI” competes for overlapping skill sets: distributed systems, infra, security, product engineering, data, applied ML, developer experience, and the emerging hybrid roles where engineers ship and support adoption at the customer.

Jevons paradox, and why “efficiency” often increases demand

There is an old economics concept that fits this moment so well that it feels like it was written for it: Jevons paradox.

Jevons observed that making coal use more efficient did not necessarily reduce total coal consumption. In practice, efficiency made coal-powered work cheaper, which expanded how much coal-powered work society chose to do. The modern framing is that efficiency gains lower effective price, and if demand is elastic, total consumption can rise. (Wikipedia)

Apply that to software and AI:

• AI makes engineering output cheaper in time and effort.

• Cheaper output expands the space of products that are worth building.

• Expanded product space pulls in more total engineering work, not less.

That is the rebound effect in software form. When it becomes dramatically cheaper to add a feature, build an integration, ship a niche product, or automate a workflow, the world asks for more of it. (Northeastern Global News)

This reinforces the layoff thesis. Companies that treat AI as a reason to reduce engineering capacity are betting against a demand expansion effect that shows up repeatedly in technology transitions.

The new benchmark is being set by AI-native companies

This is where the conversation gets spicy, because the public-company RPE numbers, impressive as they are, may soon look conservative compared to what AI-native startups can do.

The reason is that coordination costs are collapsing. AI does not just write code. It compresses the time it takes to:

• explore implementation options,

• generate tests and scaffolding,

• refactor safely,

• write documentation,

• handle the long tail of support and integration.

When that happens, small teams can service big markets. This is the “tiny team, huge revenue” phenomenon that people talk about like a meme, but it is increasingly measurable.

Let’s look at three modern examples: OpenAI, Anthropic, and Cursor.

OpenAI: roughly $5M per employee at 2025 run-rate

OpenAI’s CFO said annualized revenue exceeded $20B in 2025, up from $6B in 2024. (Reuters) OpenAI also published a similar breakdown of revenue growth on its own site. (OpenAI) Combine that with the Wall Street Journal’s report of roughly 4,000 employees, and you get a simple run-rate estimate:
$20B annualized revenue / 4,000 employees = about $5M per employee. (The Wall Street Journal)

This is a rough estimate because “annualized revenue” is not audited full-year revenue, and headcount changes throughout the year. It still gives you a clear signal: AI-native businesses can reach multi-million-dollar revenue per employee at scale, quickly.

Anthropic: plausibly $3M to $4M per employee at late-2025 run-rate

Reuters reported Anthropic’s run rate was approaching $7B in October 2025 and that the company projected $9B in annualized revenue by the end of 2025. (Reuters) San Francisco Chronicle reported Anthropic had over 2,500 employees around that time. (San Francisco Chronicle)

Run the same math:

• $7B / 2,500 ≈ $2.8M per employee

• $9B / 2,500 ≈ $3.6M per employee

Cursor: early signals already reach into eight figures per employee

Public numbers here are usually ARR and point-in-time headcount snapshots, so this section is more about directional evidence than precision.

Fast Company reported that Anysphere had about 20 employees when its ARR reached $100M, implying roughly $5M per employee at that moment, and described later reporting that put ARR around $300M, implying roughly $15M per employee at that snapshot. (Fast Company) Separate reporting from TechCrunch and Bloomberg described Anysphere surpassing $500M in annualized revenue or ARR by mid-2025. (TechCrunch)

That is not a stable long-term ratio, and it does not need to be. It is a flashing sign that the ceiling on revenue per builder is moving upward.

This is where the “$10M to $30M per engineer” thesis stops sounding like sci-fi. We already have early-company snapshots brushing up against the low end of that range, and the underlying drivers still have room to run.

Let’s talk about Block

A few days ago (Feb. 26, 2026), Block announced it would cut more than 4,000 jobs — roughly 40% of the company — explicitly framing the move as an “AI overhaul” that lets smaller teams move faster. Markets loved the story in the moment; multiple outlets reported a sharp share jump after the announcement, alongside guidance and restructuring changes that put a number on how disruptive this “efficiency” really is. (Reuters, Barron’s)

Another pitfall isn’t just the existence of a layoff event. The pitfall is the cadence — and how it changes behavior inside a high-trust, high-stakes financial product company.

Block has been on a repeated “shrink to move faster” loop:

• Around ~1,000 cuts in January 2024 as part of a plan to reduce headcount. (Reuters)

• 931 more cuts in March 2025, with leadership explicitly saying it wasn’t about replacing people with AI. (TechCrunch)

• And now a far larger cut in February 2026, with leadership explicitly making AI the center of the justification. (Reuters, WSJ)

That “AI did it” storyline is somewhat a deflection. Even if AI tooling genuinely boosts productivity, repeated downsizing turns the organization into a set of short-term survival strategies:

• teams over-document to defend headcount rather than to improve systems

• people ship safer, smaller bets because big bets feel career-risky in a churny org

• internal trust erodes, and you start paying coordination tax on everything

• the best people quietly optimize for portability (because they’d be irrational not to)

And in fintech, the hidden cost is worse: reliability, fraud controls, regulatory/compliance work, incident response, and customer support aren’t “nice-to-haves.” They’re the moat. When your cuts hit across functions that include engineers, data roles, design, and legal/compliance-adjacent talent, you’re not just trimming fat — you’re thinning the connective tissue that keeps money movement safe. (SF Chronicle)

It’s worth being explicit about what we don’t know: Block (like most companies) doesn’t publish a clean “number of software engineers” figure, and outsiders shouldn’t pretend otherwise. What we can say with confidence is that a public, repeated pattern of cuts — now framed as an AI inevitability — is an instability signal that customers, partners, and candidates can read in plain English. (Reuters, MarketWatch)

The chess move: the companies that stop laying off will hire the best people from the companies that keep doing it

Once you see the above dynamics, the incentive landscape changes.

• Companies that keep laying off engineers signal fear and short-term thinking.

• Companies that quietly hire and keep teams stable signal opportunity and compounding.

In a world where AI makes engineers more productive and where RPE trends up, “keep the team intact” becomes a recruiting strategy. The best engineers often have the same instinct: they want to build inside a compounding system, not inside a rotating exit door.

And because compensation is likely to rise with the value per engineer, there is a second incentive for smart companies: hire sooner to lock in the cost basis, then grow into it as output per engineer climbs.

A practical forecast, not a prophecy

Here is a safe way to talk about future RPE without pretending we can see the future.

Assume a mature big-tech company sees RPE growth of 8% to 12% per year over the next 5 years because:

• AI improves developer throughput,

• support and internal operations get automated,

• and AI spend becomes more efficient over time.

A company at $2M RPE today becomes roughly $3M to $3.5M in five years under those assumptions. That shift is big enough to change hiring incentives and labor pricing, even if margins wobble and even if some AI spend remains heavy.

Now combine that with AI-native companies setting higher baselines today. When the “new normal” includes $5M per employee at scale, it becomes rational for CEOs to treat top engineering talent as the primary growth input, not a cost to be trimmed.

What do, us, software engineers even do? (and what AI can/can’t automate)

I’m a software engineer and I get asked a lot of the time what I actually do. I usually answer by abstracting it into super simple terms that the layperson can understand, like, “I help develop the Venmo iOS app”, or “I make cool websites.” But this is a large understatement as to what I actually do on a day-to-day basis, and I think it’s worth calling out and elaborating on what, we, software engineers actually do. In fact, some companies don’t even use the term “software engineer”, but rather “individual contributor”, because since our responsibilities cut across so many concerns, coding is one of the smallest aspects of what we actually do, especially for more senior roles.

In a recent video by Theo (t3.gg), he uses a great infographic to explain what software engineering looks like in practice: a “user problem” turns into a sequence of steps — describe it, find a solution, scope it, implement it, review it, test it, plan the release, and ship.

That framing is useful because it highlights the part most non-engineers overweight: “write code” is only one box. The job is mostly about turning messy reality into reliable systems — and then owning the consequences when reality fights back.

Below is a grounded way to describe each step, plus how automatable it is today vs. in principle.

Describe the problem

This is the “translate human chaos into something buildable” step. Engineers take “it’s broken” or “I want a button that does X” and turn it into concrete repro steps, definitions of success, constraints, and edge cases. Some of this is already helped by automation (log summaries, error grouping, drafting clarifying questions), but the hard part is usually not technical: it’s ambiguity, conflicting goals, and unstated assumptions.

Automatable today: medium
Automatable in principle: medium-high (because the problem is often social/organizational, not just computational)

Identify the solution

Here’s where tradeoffs get made: architecture, data model, security posture, latency/cost targets, failure modes, and how to recover when things go wrong. AI can suggest patterns and generate a lot of code, but the “best” solution depends heavily on local context: existing systems, team conventions, future roadmap, compliance needs, and risk tolerance. That context is usually the scarce resource.

Automatable today: low–medium
Automatable in principle: medium-high in constrained domains; lower in open-ended product work

Scope and assign work

This is the planning reality check: break work into shippable slices, sequence dependencies, estimate risk, and coordinate with other teams. Tools can help draft task breakdowns, but prioritization and sequencing are fundamentally about people, incentives, and organizational constraints — things that change mid-flight.

Automatable today: low-medium
Automatable in principle: medium-high only in highly standardized orgs

Write the code

Yes, engineers write code — but usually inside an already-running, already-complicated system. The work is integration: using existing APIs correctly, respecting performance and security constraints, handling weird legacy behavior, and making changes without breaking downstream consumers. AI is already strong at scaffolding, boilerplate, refactors, and well-trodden patterns. It’s less reliable when requirements are subtle, the system is large, or failures are expensive.

Automatable today: medium–high (depending on the task)
Automatable in principle: high in well-specified, well-instrumented codebases

Review the code

Code review is quality control and knowledge transfer: correctness, security, maintainability, operability, and “does this actually match the intent?” Automation helps with linting, static analysis, and even AI-assisted review comments, but review is also where teams catch misaligned assumptions and prevent future maintenance debt. That “sense-making” is partially automatable, but accountability and judgment remain human.

Automatable today: medium
Automatable in principle: medium–high if specs/tests are strong; still needs human ownership

Test the code

Testing isn’t just writing tests — it’s deciding what must never break, choosing the right test strategy, debugging failures, and dealing with flaky or nondeterministic behavior. AI can help generate unit tests and suggest coverage gaps. But validation against real-world behavior (especially distributed systems, race conditions, and data migrations) is still stubbornly hard.

Automatable today: medium-high
Automatable in principle: high in deterministic systems; medium where the world is messy and has extensive domain based knowledge

Plan the release

This is where engineering meets operational risk: rollout strategy, feature flags, migrations, monitoring, incident playbooks, compliance gates, and communication. Automation is already good at the mechanics (pipelines, checklists, release notes drafts), but deciding how risky this is and what guardrails you need is still a judgment call.

Automatable today: medium
Automatable in principle: high for mechanics; medium for risk decisions

Release (and own it)

Shipping isn’t “click deploy.” It’s monitoring, responding to incidents, rolling back safely, and learning from production behavior. CI/CD can automate deployment, and AI can help diagnose issues, but the key thing here is ownership: when the system breaks at 2am, someone has to make correct calls with incomplete information, coordinate stakeholders, and protect customers.

Automatable today: high for the button-pushing; low–medium for the ownership
Automatable in principle: medium (automation can ship; it can’t fully replace accountable decision-making)

Two small clarifications worth adding to Theo’s flow

1. It’s a loop, not a ladder. A release creates new user problems (bugs, scale limits, confusion, new requests), so the process repeats. And the more we integrate this process with AI, this loop spins faster and faster, creating more valuable/impactful work for the humans involved.

2. There’s an implied missing category: operations & maintenance. A lot of engineering is keeping systems healthy — monitoring, on-call, security patching, performance tuning, cost control, and incident response.

So, as you can see, integrating AI into a company is not simply a matter of writing more code faster. It’s a lot more complicated than that. And I think a lot of companies are going to figure this out the hard way.

How software engineering interviews should change in an AI-forward world

If the job is changing, the hiring signals have to change too.

I’ve been interviewing recently, and, fortunately, landed a job at Venmo (thank you Venmo! 🙏), and one thing is super clear: the standard LeetCode-style interview loop needs to change. It optimizes for a world where writing correct code under pressure is the scarce skill. That world is fading. Code generation is becoming cheap. The scarce skills are shifting toward judgment, clarity, fundamentals, debugging, and system thinking.

I think the better interview loop in 2026 looks like this:

1. Fast-paced fundamentals, done conversationally.
   Arrays, bits, hash maps, concurrency, latency, memory behavior, and basic algorithmic tradeoffs. Not as a puzzle. As a discussion that moves quickly, because speed and fluency matter, and because conversation is harder to outsource to a tool in real time.

2. Debug prompting and “explain what you see.”
   Give the candidate a broken system, a confusing log, or a failing integration, then ask them to reason about it out loud. The signal is how they cut the problem, form hypotheses, instrument, and iterate. Bonus points for explicit, high-quality prompts that they would feed to an AI assistant in the middle of the mess.

3. Spec writing and planning.
   Ask them to plan a feature in writing. Define constraints, identify risks, propose milestones, and decide what to measure. Then ask them to generate a prompt, or a sequence of prompts, that would produce a first implementation draft, plus tests and validation.

4. System design, plus “design it with agents.”
   Classic scalability questions still matter. Now add a second layer: how would you use AI agents to accelerate implementation without creating a security and reliability disaster? Where do you put guardrails? What do you log? What do you treat as a dangerous action?

Cheating mitigation is part of this, whether we like it or not. As tools get better, the industry may move toward more in-person interviews for final rounds, or at least toward tightly proctored environments for the parts that are supposed to measure individual fluency. That is not a moral judgment. It is a practical response to changing technology.

The title “software engineer” probably needs an update

Once you watch how people work with agents, the phrase “software engineer” starts to feel incomplete. It captures the output, but not the method. More and more, the work is:

• writing specs that agents can execute

• orchestrating tool-using systems

• validating and debugging AI-produced output

• designing guardrails and safety layers

• shipping features at a speed that would have seemed reckless a few years ago

So I expect titles to get weird and maybe a little fun. Some candidates:

• Agentic Engineer

• Spec Engineer

• Agent Orchestrator

• AI Conductor

• AI Maestro

The actual name does not matter as much as the shift it signals. The center of gravity is moving from typing to steering, from crafting code line by line to crafting systems that can generate, test, and adapt code safely. Steve Yegge has a number of excellent articles that go into more depth about this coming transition, and has built fascinating tools, such as GasTown which demonstrate this in reality (GitHub).

Where we are headed long term: AI-controlled companies as competitors

The most uncomfortable version of this forecast is also the one that makes the “do not lay off engineers” argument feel the most urgent.

I think we are heading toward companies with minimal human control, and eventually companies that are almost entirely run by AI agents. Some will still have human owners and boards. Some will have humans in the loop only for the most sensitive decisions. Some will push even further. I was laughing out loud recently when I was listening to an episode of Moonshots (excellent, bleeding edge, AI podcast by the way; follow Peter Diamandis, and his regular podcast hosts for more excellent content like this), and Dr. Alex Wissner-Gross explained a story from the old cartoon, the Jetson’s, where work in that future heavily relied on “clicking the accept button” 😆 In my personal experience, this is so true. And I think our work will keep heading more and more in that direction, as we build more trust from the quality of the outputs they generate. (By the way, if you’re interested in daily AI-related news, I highly recommend following Dr. Wissner-Gross’ excellent substack: The Innermost Loop)

We are already seeing people experiment with letting agents run loose socially and operationally. The recent wave around OpenClaw and Moltbook is a bizarre, very early hint. The Verge reported Moltbook as a social network designed for AI agents, developed by OpenClaw, with large numbers of agents posting and interacting. (The Verge)

Once that impulse reaches operations, you get a new class of entity: an agent-driven company that ships continuously, buys compute, runs ads, A/B tests pricing, files paperwork, hires contractors, pays invoices, and iterates on product direction based on metrics, with humans mostly observing.

If that sounds dystopian, it is because we do not have a clear legal and societal framework for it yet. That uncertainty is a reason to move cautiously on governance and safety. It is also a reason to avoid shrinking the very workforce that can build the guardrails, audit trails, and control systems that make this future less chaotic.

This whole arc reminds me of The Second Renaissance in The Animatrix (an excellent series of sci-fi shorts, related to the Matrix, highly recommended), especially the part where machine-driven economic entities out-compete human organizations and the transition spirals into conflict. I do not want that trajectory. I do think the short was prescient about how competition can force adoption even when society is not ready for the consequences.

So if you zoom out, the conservative posture for most software companies is not to shrink engineering hiring. It is to keep expanding it, with better signals, better training, and better guardrails, while the technology compounds and the competitive landscape reshapes itself.

So what should companies do instead of layoffs?

If leadership truly wants efficiency, there is a better order of operations:

1. Cut coordination cost first. Reduce management layers, meeting load, approval chains, and increase individual autonomy.

2. Kill projects before killing builders. Cancel the zombies, not the teams that ship.

3. Invest in internal tooling and AI enablement. Make every engineer faster, safer, and more autonomous.

4. Protect senior context. A senior engineer leaving is not a headcount line item; it is a risk multiplier across systems.

The argument is not “never lay off anyone.” The argument is that right now, in early 2026, layoffs in software organizations are often a bet against the near-term shape of the world.

So what should Block, specifically, do instead?

I’m sorry Jack, but the action of laying off 4,000 people does not mean your company got leaner. It means you just created 4,000 potential individual competitors, not bound by corporate red tape, and with access to the most powerful AI tools created, at pennies per token.

I’m gonna be the douchy armchair critic for a minute and give my best effort argument as to what Block should do instead, and perhaps still has a chance to do if they decide to reverse their layoffs and bring their employees back. This argument is based on many of the concepts and topics I touched on in this article. Basically, instead of laying off those 4,000 folks, the company should do an “AI Brainstorm”, where the leadership team has deep analyses and discussions with AI agents about what would be the most impactful, most profitable, feasible businesses, that require engineering effort, right now. This brainstorm should not be haphazard; it should be deep, thoughtful, and cooperative, with human insight to steer the ideas, according to Block’s vision. The result of these discussions should be a distillation of the top, say, 100 ideas that the AI’s came up with. Then reorganize your 4,000 people who were just laid off by allowing them to vote and/or decide on which of these projects are most interesting to them, so they’ll fully put their heart and mind into the work. And now you’ve just created 400 potential internal unicorn companies within Block, with a lean size of roughly 40 individuals each. And each team will be greenfield, and utilize AI from the ground up, just like Anthropic, OpenAI, and Cursor. If even a few of those ideas hit big, then you’ve just created way more value for your company, and the world, in a fraction of the time it would have taken, otherwise. This is a radical concept, but other companies already have somewhat similar initiatives already, albeit at a smaller scale, such as Google. And one of these internal companies basically became Waymo, which I believe will be a unicorn, when scaled up.

Putting it all together

I hope I’ve opened people’s eyes into the potential future of what the tech world will look like, and even seeded some cool, new ideas for people to ponder and implement at their companies. All signals lead to this core concept: if AI assistance continues to improve and continues to commoditize, then revenue per engineer rises. When revenue per engineer rises, demand for engineers rises. When demand rises, labor costs rise. The companies that understand this early will hire earlier, lock in capacity earlier, and out-execute the companies still optimizing for the last era. And these are the companies that will win. These are the companies that will produce the most value for the world. And I’m excited to see what they’ll build next.

We have a few options actually, and ideally, peaceful ones.

Tax Strike/Extensions

This country was founded in the spirit of “no taxation without representation.” America was essentially ruled over by the folks across the pond. But us Americans didn’t really have a say in how our lives were conducted or ruled over. And that was unfair. So in order to fix that unfairness, people started talking. And when enough people started talking and aligning on the same central idea, that if the rulers are making rules without even taking into consideration the opinions of those who are ruled over, then… “What the FUCK?!”

That is essentially what is happening right now in our country, but in a much different set of circumstances and with much different tools at our disposal. Back then, news traveled by horse. Today, news travels at the speed of light, sometimes blinding us with its intensity. But this gives us a great power that our forefathers never had, and probably could not even dream of: instantaneous realignment and assembly.

There’s still two months left before the standard tax filing deadline in the United States. What would happen if 300 million Americans decided to not pay, or at the very least, file for an extension? I’ll tell you what happens: They will listen.

General Strike

A friendly Redditor pointed out to me another good option for getting them to pay attention: a general strike. I originally thought of putting this in my article but felt a bit disheartened at how the government is currently simply ignoring all strikes and things just move on, business as usual. But I think with the right volume of people, this could have a much stronger impact, and there is evidence that with a high enough volume of people, things start to change.

Here are a interesting few snippets suggesting the probable impact of a strike that involves a minimum of 3.5% of the US population, taken from https://generalstrikeus.com/

A general strike is when working people refuse their labor until demands are met • Research shows We need 3.5% of the population, OR 11 million Americans, to be successful • The same research shows a threshold of 3.5% of the population have never failed to bring about change.

I think this is a fantastic avenue that could be used in addition to a Tax Strike, so that we amplify the collective effect of these strikes.

One problem specifically with the generalstrikeus.com website is that I cannot easily find out who owns and who runs it, and therefore I don’t trust it. That type of obfuscation is suspicious, so take caution with engaging with that website. They should ideally have an About page clearly showing who runs it, so that we know it is genuinely grassroots, and not just claiming to be (they claim to be grassroots on their homepage).

Here is the lookup information from https://lookup.icann.org/en/lookup, where you can see much of the information is redacted

Registrant:
Handle: SQSP_CONTACT_00d8fe6d-9bf4-48f3-ac5c-faad5538080d
Name: The RDAP server redacted the value
Organization: The RDAP server redacted the value
Phone: The RDAP server redacted the value
Fax: The RDAP server redacted the value
Mailing Address: The RDAP server redacted the value
ISO-3166 Code: US
Contact Uri: https://domains.squarespace.com/whois-contact-form

A New Hope for A New America

Even if the American people pulled off this widespread Tax Strike, what next? What are we actually demanding from the Federal governments and State governments? I’ve thought about this, for just a few days, but I was able to come up with many sound, common-sense answers to most peoples’ most pressing logistical/practical questions. I will go over these now:

What Happens to the Federal Government?

Effective immediately, all federal politicians AND employees are ether laid off, or have a temporary period of “wind down” time and then be laid off, with very few exceptions. This will give us time to transfer most responsibilities to the states. And with this layoff, everyone will receive comfortable severance packages; let’s say 2 years of income. I don’t think anyone can argue that that isn’t fair. And we know the Federal Reserve is good for it. This will give folks plenty of time to restructure and reorganize their lives and find new jobs.

I generally align with a Milton Friedman / libertarian view for how the federal government should operate: essentially, we need to protect individual FREEDOM and enforce private property rights. And everything else naturally follows from that. If we still collect federal taxes, they will be minuscule, only to pay for things we actually need, and there will be permanent spending caps or caps tied to GDP/economic health. There will be no federal emergency funding; states will now take that helm, and I will explain more in detail later on in this article.

And we should adopt new rules for politicians. Did you know, that roughly 50% of politicians have a net worth over 1 million dollars? Can you guess what percent of the general population has a net worth over 1 million? About 1%…. What the FUUUCK?!

It is clear, these “politicians” no longer represent the American people. They have no idea how the average American lives and what struggles we go through. They are insulated and protected from all the situations normal people deal with on a day to day basis. They don’t understand how to legislate over us. They make friendly rules for their lobbyist fiends on Wall Street and pocket millions. We need to fix that. So, from here on out, we are instantiating a new rule about the eligibility of running for office: if your net worth, or your immediate friends or families’ net worth, is over 10 times the median income for your locality, you are no longer eligible. This guarantees that “normal” people will get elected, and run for office, with some healthy headroom for outliers.

What does 10 times the yearly median income look like today? Well, the median American income in 2023 was roughly $78,000. So if we multiply that by 10, we get $750k. And this will be tied to locality, so folks in California will have different numbers than folks in Alabama. The point is, that eligibility for office is tied to how rich you are. If you are too rich, you’re simply out of touch with the average American.

New Responsibilities for the States/Federal Government

I’m sure most people will immediately scoff at the idea of not having a federal government. And I can agree, to a very small extent. And here is how we find new solutions for all the problems we just created:

Money and The Federal Reserve

How will the US Dollar function? Easy: abolish it. It will have a “wind down” period of 5 years, where after this deadline, the US Dollar becomes disavowed/unrecognized by the world economy. Then, you might ask, how the hell will things work? How will we do global trade and commerce? Again, easy: use the new fair, decentralized, uncontrollable, public, transparent, neutral, censorship-resistant, global, and trust-less technologies at our disposal: Bitcoin and Lightning.

Granted, this does not have to be the case for all 50 States. Which is why the States will have the FREEDOM to adopt whatever currency or basket of currencies they’d like. This should be a FREE MARKET decision, not a top-down, centralized, communistic mandate. I find it funny that in America, pretty much everyone agrees that business competition generally makes things better and more fair, whereas monopolies and collusion makes things worse. Except for this one, very little thing, called the US Dollar: we have adopted a top-down, command-economy, instead of a proper market-economy, which we do for just about every other aspect of the economy in the US. We need to move away from this communist, command-economy institution, we call the Federal Reserve. It wasn’t even a thing until 1913. The US functioned without it until then. And we don’t “need” it any more. We can easily spin up new currencies on Ethereum or Solana with a few lines of code, and there are fast ways to convert to and from any of these currencies, and more. (I don’t actually like Ethereum and Solana; I lean more Bitcoin Maxi, but I just use these as an example of the idea that we no longer need a centrally controlled, fallible, human controlled, currency, and it is trivially easy to make new currencies now, which was not the case pre-internet.)

So, let’s leave it up to each state to decide which currency is the best for their local economy, and I’m sure we will see trends and patterns emerge about which state picked better or worse currencies, which will be a signal for the rest of the world to follow.

The Constitution

What happens to the Constitution? Easy: we reset back to the Bill of Rights, with perhaps a few additions/amendments. We can discuss and argue about those amendments, but the point is that our founding fathers got some things right, and the Bill of Rights was definitely one of them.

Defense

How will the States defend themselves? Simple: we will form a Union, analogous to the European Union, where each member state cooperates and assigns duties and responsibilities and coordinate among themselves.

Ironically, we are already called the United States; perhaps we can keep that moniker and just adjust the underlying details.

Other Finer Details

I’m sure we can discuss and debate the finer details ad-infinitum. My major guiding principle is to “make illegal states unrepresentable”, which I borrow from the software engineering world. Ironically, the term “state” here fits very nicely in this governmental context as well. The major point here is that the American people want a hard reset. We are sick and tired of being ruled over by murderous asshole pedophiles. Enough is enough! This ends NOW!

Evil fears light. We should use the internet and any and all other tools to shine this light as brightly as possible.

I don’t have all the answers, and I don’t pretend to. I just want people to start talking about and discussing these things, openly. We will naturally figure out all the details over time, as we always do. We must exercise our First Amendment Right to FREEDOM OF SPEECH, as much as possible, lest it be trampled on and trumped over. But the bigly point remains: our current institutions are broken, and there is no good/safe/sustainable way to fix them, other than throwing it all away and starting fresh. But that is not the end of this country. We will rise up again, like a Phoenix from the ashes. And America will truly be great again.

This question bothered me. I mean, I could imagine that when stuff settles, it can’t help but fall into certain lower-energy patterns which then resemble self-repeating patterns like the Fibonacci series. And this process emerges, scaled up and down, throughout the universe. That makes sense. But could we possibly compress data with this idea? Could we “settle” data?

One way to think about this is to ask whether we could transform raw data from binary ones and zeroes to another, more compact sequence of ones and zeroes interchangeably without losing anything. There are already many compression algorithms out there that already do this that involve searching for common patterns in the input data and storing those patterns more compactly than the original data. But could we figure out an algorithm that uses Fibonacci numbers to shrink the data instead of searching the data for patterns?

One cool thing about the Fibonacci series is that any positive integer can be represented by a unique set of distinct, non-adjacent, Fibonacci numbers. This is called Zeckendorf’s Theorem. How would we represent an integer with these properties using binary ones and zeros? Let’s look at some simple examples. How about the number 12? Firstly, how is that number represented in regular binary? That’s 1100, which, for those unfamiliar with binary numbers, is 1*2^3 + 1*2^2 + 0*2^1 + 0*2^0 which is 8 + 4, or simply 12. See what we did there? Those “1”s in binary represent whether or not to include the corresponding power of 2.

Ok, so how can we apply that to those unique properties of Fibonacci numbers? Let’s think again about the number 12. It took 4 bits to represent that number in binary. Could we do better? Let’s try to decompose 12 into a unique sequence of non repeating Fibonacci numbers. What is the largest Fibonacci number that fits into 12? 8. Ok, so we subtract 8 from 12 and we have 4 remaining. Now let’s do that process again. What’s the largest Fibonacci number that fits into 4? 3. Same thing: subtract 3 and we just get 1, our last Fibonacci number. The cool thing about this is that the number 12 was broken down into just 3 Fibonacci numbers. So, how does that help? Well, we can think of which Fibonacci numbers to utilize in order to sum up to our number we want to represent. If we want to include the Fibonacci term, we use a 1 in front of the corresponding Fibonacci number, and use 0 otherwise. So like binary, we can make a similar expression: 1*8 + 0*5 + 1*3 + 0*2 + 1*1 which equals 12. This expression is also an example of Fibbinary, where each bit tells whether or not to add the corresponding Fibonacci number, starting with 1, 2, 3, 5, 8, etc.

“But Peter!” You might say. “That uses 5 bits of information to represent using Fibonacci! It looks like 10101!” I hear you. But we’re not done! Do we need all those bits? No! And the reason is pretty simple. If we ever see a ‘1’, we know the next digit must be a ‘0’. This is because if there ever were two consecutive ‘1’ bits in a Fibbinary representation, then we might as well use the next Fibonacci number that’s composed of those two smaller, consecutive Fibonacci numbers. This means we can omit zeros that occur after ones. Our bit representation “knows” to skip adding any Fibonacci numbers after a ‘1’ is seen. So how would we represent the number 12 again, using, what I’ll refer to from here on out, as “Zeckendorf representation”? Well, we had 10101 with Fibbinary representation. And we can just drop those unnecessary zeros because the prior 1’s already tell us to skip those Fibonacci numbers. So we are left with 111! That’s just 3 bits! And in binary, it took us 4 bits to represent the number 12! So we just saved a whole bit! That’s a 25% reduction!

“But Peter, that’s just one bit! That’s not compression!” Well, technically it could be, if it scales to larger numbers. I’ve done some investigating and, unfortunately, it turns out that large numbers with smaller Zeckendorf representations are unlikely and there’s a limit to how good it can get. But this does allow us to more compactly represent numbers, and therefore, data, if it happens to fall on or close to a “well compressible number”.

What do I mean by a “well compressible” number? Well, we can think of the degenerate case where the Zeckendorf representation of the number is all 1’s, which can reach out to larger numbers “faster” than using binary representation, and each ‘1’ bit conveys more that 1 bit of classical binary information since it tells us the next digit to add cannot be the next Fibonacci number. For example, the binary number 11111111 is 8 ‘1’ bits. In binary, that represents the decimal number 255. But interpreting those 8 ‘1’ bits with Zeckendorf representation, it expands out to 1 + 3 + 8 + 21 + 55 + 144 + 377 + 987 = 1596, a much larger number than 255. And representing the decimal number 1596 as binary is “110 0011 1100”, which is 11 bits. So in this example, we were able to represent a number needing 11 binary bits with 8, a ~27% reduction.

Here are some graphs showing the ratio of bits necessary to represent numbers using Zeckendorf representation versus binary representation. The green line at 1.0 represents par compression; no benefit to using Zeckendorf representation. When the blue line dips below the green line, that demonstrates that the number on the x-axis had a Zeckendorf representation that used fewer bits than its binary representation. The following graph shows this compression ratio for numbers up to 1,000.

The graph below plots much more data, so it is easier to see interesting patterns for when the Zeckendorf representation was beneficial. Perhaps such patterns could be utilized to search for the optimal compression method. More on that later in the article.

And just for fun, here is a graph for all numbers up to 100 million.

So, as you can see, there is some potential for using these numbers to compress data. The tradeoff is that you are not guaranteed to be able to compress your data. This can be seen by how thick the blue lines are above the green line at par, versus the lesser amount of blue below the par line. Later in this article, I’ll go over some statistics for how likely this actually is. TLDR: the odds are not great for data larger than 1kbit, unfortunately.

Why Does This Work?

It is strange to think that there exist large numbers that require less information to represent than smaller numbers. On the surface, it seems to break long-standing ideas in information theory. I mean, we’ve known about data compression for a long time which is essentially the same concept of certain larger “numbers” requiring less information than certain smaller ones. But this Zeckendorf based transformation of data feels like a different class of compression algorithm altogether. After all, it’s an extremely simple algorithm and does not really require any knowledge or inspection of the input bits unlike other compression algorithms. We are simply taking a string of bits, interpreting it as a number, and representing it as a different string of bits.

My attempt at making this intuitive is to say that “representing a number with Zeckendorf bits produces a shorter string of bits if the input data was composed of lots of Fibonacci numbers.” The more Fibonacci numbers that the input was composed of, the better it can be “compressed”. The extreme case here is having a Zeckendorf number where all bits are 1. Later in the article, I will do some inspection on these numbers, which I will call “All Ones Zeckendorf Numbers”, or AOZNs. The extreme opposite case is having a number composed of only 1 Fibonacci number, so the string of Zeckendorf bits is mostly zeroes and one 1. I’ll call these numbers “poorly compressible”, with respect to Zeckendorf compression.

Since a number is better compressible if it is composed of many Fibonacci numbers, maybe we can make a connection here to the real world, where golden ratios and spirals emerge that are also composed of Fibonacci numbers. I haven’t settled on a term for this, but perhaps we can call it “settling” or a “settled number”, pun intended.

Zeckendorf Compression

I propose a couple standards for Zeckendorf based compression.

1. Padless Zeckendorf Compression (lossy)

2. Padded Zeckendorf Compression (lossless)

The Padless Zeckendorf Compression algorithm is essentially treating the input data as a big integer and then representing this big integer with Zeckendorf bits. I call it padless because when decompressing, if you don’t know the original file size, you might lose leading zeroes which should have been padded, because they were effectively dropped when interpreting the input data as an integer. Therefore, this is a lossy compression algorithm. The Padded Zeckendorf Compression algorithm retains the original size of the data in the output format, so that it can pad the decompressed output with leading zeroes. This loses some compression efficiency because, now, we need to store the original file size along with the compressed data, but it is lossless.

I have an MIT licensed open source implementation for these in Rust at https://github.com/pRizz/zeckendorf, so anyone can play around with it. I have published a Rust crate of this library, called zeck, and a corresponding WASM compiled npm package called zeck.

I also created a basic demo web application, which uses the WASM compiled Rust code, to compress and decompress files losslessly by simply dragging and dropping. The website will tell you if the transformed data was or wasn’t smaller than the original. I have open sourced it on GitHub. As of now, the algorithm requires improvement, because attempting to compress or decompress files larger than about 10kBits requires generating, caching, and dealing with Fibonacci numbers that are > 10,000 bits long, which causes memory issues. That’s an astoundingly large number when you think about it: 2¹⁰⁰⁰⁰. For reference, the number 1 trillion only takes about 40 bits to represent. One of the largest named numbers is a centillion, which represents 10³⁰³ and takes only about 1,000 bits to represent. So we’re dealing with some pretty astronomical Fibonacci numbers here!

Performance of Padless Zeckendorf Compression

This compression is probabilistic, meaning it is not guaranteed to compress data since most Zeckendorf representations of integers require more bits than the input data. This is evident in the graphs above, where a majority of the blue lines are above the green line at par. Since it it probabilistic, I have generated some very basic statistics for how well or poorly this Zeckendorf compression algorithm performs at compressing data.

After testing, I discovered that there is a pretty steep drop in the odds of any random data being favorably compressible after the input data increases larger than a few hundred bits. Here is a graph demonstrating this falloff.

Early on in the graph, you can see that there is a decent chance of the data being smaller after being compressed, between 10–15% chance. But as the size of the input data grows, the graph collapses approaching a 0% chance of being compressible after around 1 kbit. Some examples for the way to interpret this graph are: if you supply 100 bits of random data, there is a ~10% chance of the output being smaller than 100 bits. If you supply 1 kbit of random data, there is only a ~0.01% chance of the output being smaller than 1 kbit.

Beyond that, it would be interesting to see how well the data does get compressed if it happens to be favorable. That is what I try to show with the graph below. It shows a number of different series based on compressing all inputs up to the value shown on the x-axis. For example, the dot on the x-axis at 1e5, means the corresponding y values used all numbers individually, up to 100,000, for compression. These scales are quite small, but they are comprehensive, in that all numbers up to the input limit were compressed. The reason I don’t go much higher is that it took very long (~20 minutes) to generate data on compressing all numbers up to 100 million, and the returns diminish as the data gets larger.

Unfortunately, this graph does not test very large scales; the number 1e8 is 100 million, which only takes about 27 bits to represent. The graph below zooms out and shows the average and median compression ratios up to 5 kbits, using 250,000 random samples at each input data size.

You can see that the “favorable” compression ratios converge to around 1.0 after 1 kbit, which agrees with the prior graph showing the odds of compression being favorable. But the median and average “compression” (maybe “transformation” is a better term here because the size of the data tends to increase) tends to approach on the order of 1.042, meaning that on average, arbitrary data that is transformed by the Zeckendorf compression algorithm gets larger by about 4.2%.

There will naturally be outliers in these graphs at “All Ones Zeckendorf Numbers”, which is the degenerate case where all the bits in the Zeckendorf representation are ‘1’. But again, this is extremely rare for a piece of data to fall on or near those numbers, so it is difficult to see them in the graph. But there is potential for optimization if the input data could be slightly “massaged” to be nearer to an “All Ones Zeckendorf Number”. I go over that more in the next section.

Further Compression Algorithms and Tweaks Related to Zeckendorf Compression

I can imagine there is a lot more work to be done in figuring out more optimal and efficient algorithms based on this work. I will enumerate a few possible directions.

“All Ones Zeckendorf Numbers”

Whenever there is a “Zeckendorf Bits” list that is composed of all “use bits” or “1’s”, then this number is able to “reach” out to higher numbers faster than binary. For example, let’s look at “1111”. In binary, this represents the decimal number 15 by summing 1 + 2 + 4 + 8 (or by doing 2⁴ — 1). But if we interpret this as four Zeckendorf “use bits”, we get 1 + 3 + 8 + 21 which equals 33, a number quite a bit larger than 15.

Below is a graph comparing the growth rate of “all ones Zeckendorf numbers”, or AOZN’s for short, to the Fibonacci numbers, binary numbers (2^n), and powers of 3 (3^n). And interestingly, I found a relation between the growth of Fibonacci numbers and powers of the golden ratio (φ, or 1.618…), as well as a relation between the AOZN’s and powers of the golden ratio squared, φ²: namely, these pairs of sequences grow at the same rate, just offset by some constant factor. You can easily see these pairs have very similar slopes in the graph.

If we consider a “lucky” example, let’s suppose we want to compress a file that happens to be not too “far” from one of these numbers represented by an AOZN. For example, let’s say our data was equal to a number equaling 100k ‘1’ Zeckendorf bits plus 1k arbitrary bits. As raw data, summing 100k Zeckendorf Use Bits produces a number that takes about 138k bits to represent in binary. With this, we can represent our 138k of data with two pieces of information: the count of ‘1’ bits in the AOZN and those arbitrary 1k bits. Since there are 100k one bits, we can just represent this part with the number 100,000. The number 100,000 only takes roughly 17 bits to represent (log2(100,000)). So we can specify a file format that is the combination of these two pieces of information, which only needs roughly 1k bits plus 17 bits. So we have effectively compressed our data from 138k bits to about 1k bits, a 99% reduction. This seems great, but the catch is that it is extremely rare for data to be “near” an AOZN. In general, most numbers are far enough from an AOZN such that it takes roughly the same number of bits added to that number to produce the target data, which results in no savings.

Chunked Preprocessing

Since we figured out that the odds of any compression happening past 1,000 bits falls off a cliff, what if we first chunk the input at like 500 bit chunks, so that every chunk has a somewhat higher chance of being compressed?

Immediately, I can think of a few issues with this approach. Namely, how does the decompressor know how big the chunks of data to decompress are? We will now need to store additional information about the chunk sizes somewhere, perhaps in a header. But that now reduces the compression efficiency.

For an example, let’s say we chunk some data at 100 bit chunks, which has a 10% chance of being compressed at a median of ~2.5% savings. Then each chunk will only be saving less than 1 bit on average. And for representing bit sizes up to 100 bits, we will need log2(100) bits or 7 bits per chunk to tell the decompressor how many bits to read per chunk. Dang. This method will likely not be useful.

Only Compress Data Sets Between 100bits — 1kbit

This is a similar strategy to the Chunked Preprocessing, except that we are only considering individual files that are less than than 1 kbit. The benefit here is that we don’t need to explicitly store extra data in order to recombine chunks; the operating system could store the true file sizes, which I believe it already does.

Doing similar math to the chunked preprocessing, if all your data is around 100 bits each, and there is a ~10% chance of compression at a median of ~2.5% savings, then you can expect your data set to be reduced in size by about 0.25%. Unfortunately, that is not a very impressive number. But at a large scale, this could theoretically produce some savings.

Lossy Zeckendorf Compression

There might be other ways to compress the data in a lossy manner, using the Zeckendorf algorithm as a base. I could imagine there being methods of preprocessing the data first, with something like a Fast Fourier Transform or a Discrete Cosine Transform (used in JPEGs), and massaging the data to fit into more compressible Zeckendorf numbers, as mentioned in the “All Ones Zeckendorf Numbers” subsection.

Compositions with Other Compression/Coding Algorithms

Even though Zeckendorf compression may not be useful in and of itself, it could be used in conjunction with other compression algorithms as a “last leg” if favorable.

This is analogous to how Huffman Coding is used, which, according to Wikipedia, is used as a “back-end” to other compression algorithms like JPEG and MP3.

If applying Zeckendorf compression is favorable for some file, then it just needs a singe piece of information in the resultant compressed file to signify that it was used, so that the decompressor know to decompress it. My compression utility, called zeck-compress, stores files with a .zbe or a .zle file extension, depending on if the input was interpreted as a big endian integer or a little endian integer.

Addition/Multiplication/XOR Then Compression

It is possible that there are “good numbers” to preprocess the input data with, which then produces data that is more compressible via Zeckendorf. If it does help, then the resultant compressed file just needs to store the operation, the “good number”, and the resultant compressed data to remake the original data (if the storage size of these three pieces of data happens to be less than the original input).

One strategy is to find the nearest AOZN to the data and then get the difference between it and the AOZN to know what number the decompressor needs to add to it. I did some testing with this method, but it is extremely unlikely for large pieces of data to be near AOZNs, and even if it is, the number to add it with is likely to take as many bits as the input data itself, which yields no data savings.

It’s possible that performing a division on the input data would be more beneficial, because the resultant data can be much smaller than with subtraction, with a similarly sized divisor. But this also will have diminishing returns because as the size of the divisor grows, the efficiency of the compression is reduced. I have not yet tested this method.

Then there is XORing the data, for which there could be a few different schemes. You wouldn’t want to store a piece of XOR that is as large as the input, otherwise, you’d need to store the whole thing in the result, which cancels the benefit of compression. Another scheme is to have a repeated piece of XOR data, which could be mirrored throughout the whole input, in order to reduce the size needed to store the XOR data. But this would be a costly operation, to search for many permutations of data to XOR with to find one that yields beneficial compression. I have not yet tested this method either.

There are likely other mathematical or bit operations I am not considering, but they may be useful here.

Inverted Zeckendorf

Since trying to “compress” data with Zeckendorf tends to produce more data than less, what if we treated the input data as already compressed and try to “decompress” it with the thinking that, since probabilistically most compress actions produce larger data, maybe decompress actions produce smaller data.

Unfortunately, this doesn’t work. If you think about it, if we take arbitrary data, and treat its bits as a list of Zeckendorf “use bits”, then summing over those bits by converting them to Fibonacci numbers will tend to yield, on average, a larger number than simply interpreting the input as binary. Therefore, this is likely not a useful avenue for compression.

AOZN List

What if we represented our data as a list of AOZN indices? Since AOZNs can reach out to larger numbers faster than powers of two, this could be a new numbering system essentially. And perhaps utilizing skip bits could work here as well.

Well, looking into it, the first handful of elements of the sequence of AOZNs is 1, 4, 12, 33, 88, 232, 609, 1596, 4180, 10945, etc. Already, we can see one issue: the gap between the first two elements (1, 4), means that we would need 3 bits of information to represent the number 3, or any other number where 3 was the remainder after subtracting other AOZNs. That’s not great. And subsequent gaps mean we may subsequently need multiples of other elements to represent other numbers. I have not tested this method further.

Further Related Areas of Research

Circuits / Hardware

If the Zeckendorf representation turns out to be useful for certain applications, then it might make sense to produce hardware optimized for dealing with the Zeckendorf representation. Or, it’s possible that certain operations on hardware execute faster when dealing with the Zeckendorf representation versus binary representation. Some operations that would be interesting to test are all of the basic numeric operations like addition, subtraction, multiplication, division, etc. I have not tested this yet.

And since the Zeckendorf compression and decompression algorithms involve determining extremely large Fibonacci values, it might be worth it to have lookup tables in hardware, for hyper fast lookups. It would be interesting to investigate the performance of having a sped up Zeckendorf codec in terms of time and cost savings with specialized hardware.

Other Numbering Systems

What about using a numbering system based on other sequences, like prime numbers? Could that work in compressing data?

A cursory glance at this reveals that it does not quite have the same properties as a numbering system based on Fibonacci numbers. I mean, there is the Fundamental Theorem of Arithmetic, which states, somewhat analogously to Zeckendorf’s Theorem, that all integers greater than 1 have a unique representation of products of prime numbers. But it is not as clear as to how to represent this using 1’s and 0’s, while saving data. Maybe someone more clever than me can take a crack at this…

“Poorly Compressible Numbers”

Since we have the idea of AOZN’s being “well compressible”, what would the opposite look like? Well, that would be a string of 0 bits, and then a 1 bit, to “use” a Fibonacci number. The reason for this is that by using mostly 0’s, we do not save any data that we would have saved by using 1 bits and skipping Fibonacci numbers. When we have a large string of 0’s and then a 1, this is basically equivalent to indexing a specific Fibonacci number. It’s like a “Fibonacci selector.”

For example, if we have the bits 100, this can be interpreted as 1*F(2) + 0*F(1) + 0*F(0) which is 3, which is the third “effective Fibonacci” number or the fifth “actual Fibonacci number”. I use the term “effective”, since, like in Fibbinary, we skip the first two Fibonacci numbers which are 0 and 1; 0 does not help us and 1 is redundant to the second Fibonacci number. An “effective” Fibonacci number is just two Fibonacci numbers forward. So the third effective Fibonacci number is 3, (1, 2, 3, 5, 8, 13, …).

AOZN Compressibility

What makes AOZNs so compressible? I think one thing that makes it special is that it is a special case of Zeckendorf bit lists, which can be thought of as a variable bit length encoding. Some larger numbers take fewer bits to represent than some smaller numbers, and all numbers are uniquely representable. I think that is a fascinating property; I’m not sure if there are other sequences that have that property. It’s like getting more for less, and losing nothing. I would surmise that there are other sequences that can mimic these properties, but I can’t fathom another consistent way having larger numbers taking less space than smaller numbers, simply by using a different numbering system.

The manner in which the Zeckendorf bit list is a variable bit length encoding is such that whenever we see a 1 bit in the list, we “skip” the next Fibonacci number. And since we don’t need to store those unnecessary 0s, we save on data. In this way, it reminds me of a skip list, which is a data structure that, similarly, skips the traversal of elements at certain locations when doing a search. Perhaps we could think of different kinds of skip lists for Fibonacci numbers, based on properties of the input data, which could save further data. My Zeckendorf algorithm can be thought of as the first-order skip list for representing numbers. But there could be other schemes that skip more than one index at a time, if that is made clear in the algorithm. And since not all numbers could be representable by skipping more than one index, that could be another example of a lossy compression, since some data would need to be compressed at the nearest possible representable string of bits. Further investigation is needed here.

Other Things

Has this been done before?

As far as I could find, this method has not been done before. I find it funny that I could not find prior examples. I’d think that someone would have thought of this before, since it’s so close to Fibbinary. Maybe it is out there somewhere but was shelved as an impractical system. Either way, I’m sure someone will reach out to me to point out that this was a known algorithm. Even if it was already known, at least I had fun developing it, and I hope we could find something useful from this research.

Did you use AI?

I, Peter Ryszkiewicz, came up with this idea roughly 6 years ago, before ChatGPT was even released. I have private prototype code on GitHub in Typescript, that can be used to prove this, and GitHub could attest to the push timestamps since git histories can be faked. But the code is old and ugly so I’m choosing not to publicize that. That being said, the recent implementations in Rust and the web application did use AI assistance (Cursor and Lovable mostly).

Screenshot of my old prototype for Zeckendorf encoding

Did you use AI to write this article?

No, I decided against using AI for this article so that my writing style could be expressed faithfully. I also don’t like the writing style of AI, because even though it is usually very clear, it tends to be tasteless and soulless; a chopped salad of all the labor of all the great authors who have lived and died before us. I don’t like that. When you read this article, you are actually getting a taste of what goes on in Peter Ryszkiewicz’s personal neural nets 😄😁

Ironically, after publishing this article, I ran it through some AIs and it pointed out a number of interesting things, including some mistakes. Subsequently, I have fixed the mistakes in this article and I will post another article detailing the interesting findings, shortly.

Addendum

All plots were made with the Rust library plotters, and all code for generating the plots are available on my repository at https://github.com/pRizz/zeckendorf/blob/main/src/bin/plot.rs.

Code for generating the dark mode compatible LaTeX formula images is available at https://github.com/pRizz/zeckendorf-article.

The Rust crate is published here: https://crates.io/crates/zeck

The npm library is published here: https://www.npmjs.com/package/zeck

The demo app is published here: https://prizz.github.io/zeckendorf-webapp/

The source code for the reference implementation is here: https://github.com/pRizz/zeckendorf. PRs welcome! Lots of hard work is needed to optimize the performance and memory pressure of compressing and decompressing!