The more power a person holds, the more they owe you. Not deference. Proof.

Anthony Fauci ran the National Institute of Allergy and Infectious Diseases for 38 years with a budget in the billions. Francis Collins ran NIH. Peter Daszak led EcoHealth Alliance, which channeled NIH grants to the Wuhan Institute of Virology. These are not people who deserve extra benefit of the doubt. They are people who had more to hide, more to protect, and more incentive to manage the story.

Here is what they did:

• Fauci received emails in February 2020 noting features of the genome that looked engineered. Within days, those scientists publicly dismissed the lab leak. Their uncertainty was never disclosed.
• Collins said public discussion of the lab leak could damage "international harmony." He was worried about optics, not accuracy.
• Daszak organized the Lancet letter calling the lab leak a conspiracy theory. He did not disclose his organization had funded the lab. An addendum was required months later.
• Birx admitted in 2024 that there had been a coordinated effort to suppress the lab leak theory.

By 2023, the FBI assessed a lab leak as the most likely origin. The Department of Energy agreed. The CIA followed in 2025. None of them had evidence that was unavailable in 2020. What changed was that it had become politically acceptable to say it.

The correct response is not to write this off as a few bad actors. The correct response is to update your prior.

Officials suppress questions for the same reason companies bury studies: the answer is costly to them. The incentive to manage a narrative scales with the power to do so. A researcher with no budget and no career to protect tells you what they think. One with a 38-year tenure, a congressional appropriation, and an agency to defend tells you what is safe to say.

Default distrust of powerful institutions is not paranoia. It is the appropriate prior given the incentive structure. The burden of proof belongs on the person with the power to shape the story, not on the person asking questions.

Treat official consensus as a hypothesis requiring evidence, not a conclusion that settles the question. The burden of proof belongs on whoever has the power to shape the story.

Figure: 38 — Years Anthony Fauci led NIAID while privately receiving emails flagging the virus may have been engineered, a concern he never disclosed publicly. (NIH records; BuzzFeed News FOIA release, 2021)

Myth: Officials with expertise and authority can be trusted to disclose what they know
Reality: Authority creates incentive to manage the narrative. Fauci's emails showed private uncertainty he never disclosed. Daszak had a financial stake in the lab he was evaluating. Authority and honesty are not the same thing. (House Select Subcommittee on the Coronavirus Pandemic, 2024)

Here is what works instead.

Write an audit script before you ask an agent to fix anything. The script scans the source, classifies each problem by type, scores it by severity, and emits one CSV line per unique issue. Then you hand the agent the CSV, not the file.

Two reasons CSV is the right format:

1. CSV is the most over-represented tabular format in LLM training data. The model reads it without a schema explanation.
2. One flagged CSV row replaces 500 lines of raw source content.

Six rules for the audit script:

• Classify, not just flag. `field:description rule:max-length offset:142` is fixable. "Something is wrong" is not.
• Score by severity. Group violations so the agent fixes a whole class in one pass.
• Deduplicate. One line per unique issue, not one line per row that inherits it.
• Include a snippet. Four words of context is enough to write a replacement.
• Use emojis for severity. `🔴` critical, `🟡` warning, `✅` passing. One token, full meaning, still scannable by a human.
• Normalize edge cases first. Batch fixing only works when violations look alike. Ask the agent to rewrite outliers into standard form before it starts fixing them.

The loop becomes: run script, read output, fix one severity class, rerun. No raw file. No bloated context. Just the issue list.

One reason to let the agent write the audit script: it already has a vocabulary for naming violations. When it writes the rule names and column headers, the output CSV uses the same terms it will later read. No translation step between detection and fix.

One useful pattern is to have the script produce two outputs: a compact CSV with one row per unique violation, and a second CSV that includes the surrounding lines for each offending value. The compact version drives the fix. The context version lets the agent verify that violations are similar enough to batch before committing to a single pass.

This is the same loop as test-driven development. In TDD you write a failing test first, then write code until the test passes, then rerun. Here you generate a failing audit report first, then fix issues until the report is clean, then rerun. The audit script is the test suite for your data. The difference is that you did not have to write the tests yourself.

This is what compilers have always done. A compiler does not paste your source code back and say "something is wrong here." It gives you a path, a line number, and a rule name. The audit script is the compiler for your data.

Try it on any structured file. A thousand-line source with a dozen real issues will produce a hundred flagged rows without deduplication. Collapse to unique issues, add severity scores, and you hand the agent a ten-line brief instead of a wall of text.

Anything you maintain in a structured file can be audited this way: product descriptions, design tokens, policy-checked content. Ask the agent to write the audit script, run it, read the output, and fix one severity class at a time. It knows regex better than you do.

There is a side benefit: you get observability for free. Open the CSV after each pass and watch the row count drop. No dashboard, no logging infrastructure. The shrinking file is the progress indicator.

Write a script that scans your source, outputs one CSV line per unique issue with a severity score and a short snippet, then ask the agent to fix one severity class at a time. Never paste the raw file.

Figure: n/k — Agent reads O(n) lines from the raw file, O(k) from the audit CSV. k is bounded by your rule count; n grows with your data. (Computational complexity)

Myth: Just paste the file into the prompt and tell the agent to fix it
Reality: The file fills the context window. The agent writes three fixes and runs out of room. A classified, deduplicated CSV gives the agent a map instead of the territory. (Observed session data)

An AI agent that monitors competitor releases, tracks regulatory changes, or summarises research does not want to be surprised. It wants:

• a deterministic list of what is new
• a structured format it can parse without guessing
• no rate limits tied to an advertising relationship
• no authentication wall protecting public content

RSS provides all four. Social platform APIs provide none of them. When they do, they revoke access on a quarterly basis and charge for it. An RSS feed is pull-based, open, and consistent in a way that no algorithm is designed to be, because an algorithm's job is to be inconsistent.

The clearest evidence that RSS was never really dead is podcasting. Every podcast app (Spotify, Apple, Overcast, Pocket Casts) pulls episode files and metadata from RSS feeds. The $25 billion podcast industry runs on a protocol published in 2002. Nobody disrupted it because there was nothing to disrupt: open, free, no middleman, nothing to negotiate access to. The episode is at the URL in the feed, always has been.

The same logic will now extend to any written content that agents need to reliably consume. A language model retrieving context for a user query, a monitoring agent checking for new filings, a summarisation tool ingesting newsletters: all of them benefit from a predictable, structured, chronological list of new content. That is all RSS is. The question is whether your content is reachable that way, or whether it lives inside a system that was designed for human attention and actively degrades programmatic access.

Publish an RSS feed for your content if you don't have one. Agents that monitor sources in your niche will find structured feeds before they find algorithm-dependent pages.

Figure: 100% — Share of podcast episodes distributed via RSS, a protocol from 2002 that the $25B podcast industry never replaced (Apple Podcasts Connect; Podcast Standards Project)

Myth: RSS is dead and content discovery happens on social platforms now
Reality: RSS powered the entire podcast industry throughout its supposed death; agentic AI creates a second wave of machine consumers that algorithms cannot serve (Podcast Standards Project; RSS Advisory Board)

In 2022, Sackett, Zhang, Berry and Lievens reanalysed the same literature in the Journal of Applied Psychology. The problem they identified was a statistical correction error: prior meta-analyses applied a direct range restriction correction when most hiring processes produce indirect range restriction: you select candidates on a bundle of factors, not the single predictor being studied. The correct correction changes the estimates across the board.

What the update does not do is vindicate unstructured interviews. The gap between structured and unstructured formats remains large, real, and the most consequential decision you make when designing a hiring process. Structured interviews, where every candidate is asked the same questions in the same order and answers are scored against a rubric before the hiring decision, predict performance roughly twice as well as unstructured conversations where the interviewer decides in the moment what to ask.

The mechanism is not subtle. An unstructured interview optimises for:

• confidence
• articulateness
• physical presentation
• how much the interviewer enjoys the conversation

None of those are job requirements unless the job is 'be likeable in conversations.' A structured interview forces the interviewer to evaluate the thing actually being hired for, because the questions are written in advance and tied to real requirements, and the scoring happens before anchoring bias sets in.

The practical version is simpler than it sounds: write five questions before the interview, tie each one to something the job actually requires, score each answer on a three-point scale before moving to the next, and ask every candidate the same questions in the same order. That is all. It does not require psychometric training or a formal assessment centre. It requires deciding what you are evaluating before you start.

Before your next hire, write five questions tied to the job's hardest requirements, score each answer with a three-point rubric, and ask every candidate the same questions in the same order.

Figure: 2× — Predictive validity of structured versus unstructured interviews for job performance (Sackett, Zhang, Berry & Lievens, Journal of Applied Psychology, 2022)

Myth: A great hire is obvious after a good conversation
Reality: Unstructured interviews optimise for confidence, articulateness, and likability. None of those are job requirements unless the job is to be likeable in conversations. (Sackett, Zhang, Berry & Lievens, Journal of Applied Psychology, 2022)

WhatsApp threatened Telcos' SMS revenue in a stagnant market → acquired for $19B. Uber rode a fast-growing market by scaling faster than supply and demand could naturally clear → IPO. Basecamp stayed profitable in a high-margin SaaS niche, never raised a Series A → founders exited on their own terms via secondary.

Three exits. Three market types. Three completely different playbooks:

1. Acquisition in stagnant markets: open the 10-K of the incumbent you want to threaten. Find the risk factor that names what could kill them. Build that product.
2. IPO in fast-growing markets: growth rate is the only metric that matters. Optimise for margin too early and you cede position. Whoever holds the most land when the market matures wins.
3. Profitable exit in high-margin markets: spend less than you earn from month two. Own the equity. Exit via secondary sale or dividends, with no roadshow and no lockup.

The three market types are not interchangeable. Scaling in a stagnant market funds the incumbent's comfort. Optimising for margin in a land-grab hands the market to whoever is still burning capital. Burning capital to grow fast in a high-margin niche is just paying to lose equity.

90% of successful US startup exits are acquisitions, not IPOs. Most founders spend their time optimising for a public listing that will not happen, in a market structure that does not support it.

Before writing your pitch deck, write one sentence: "We will exit via [acquisition / IPO / profitable sale] because our market is [stagnant / fast-growing / high-margin]." If you cannot complete it, you are not ready to choose a strategy.

Figure: 90% — Share of successful US startup exits that are acquisitions, not IPOs (NVCA Yearbook, 2023)

Myth: Build something great first and the exit will sort itself out
Reality: WhatsApp was not building 'for' an acquisition. But it was building in a stagnant SMS market threatened by Telcos. That market structure made acquisition the only exit that made sense. The exit sorted itself out because the market type determined it. (Thiel, Zero to One, 2014; Blank, The Four Steps to the Epiphany, 2005)

• regulatory shifts
• technology disruptions
• supply chain fragility
• customer concentration
• competitive threats

Most people skim past it. A startup founder should read it carefully. The risk factors section is, in effect, a map of the incumbent's weakest points. If a company discloses that its business depends heavily on one distribution channel, that channel is an attack surface. If it says that new technology could make its core product obsolete, that technology is worth investigating. The playbook from there is straightforward: find a risk they have disclosed, build a product that mitigates or exploits it, and sell that product to their competitors first. Once their competitors are using your product, the incumbent faces a choice: buy you or fall further behind. You do not need to win the whole market to be dangerous. You need to make their disclosed risk into a real and present threat.

Find an incumbent in your market, read their annual report risk disclosures, pick one risk you can actually mitigate, build a product around it, and sell it to their competitors first.

Figure: 100% — US public companies required by the SEC to disclose material business risks annually in their 10-K filings (SEC Regulation S-K, Item 1A)

Myth: Disrupting a large company requires secrecy until you're ready to compete directly
Reality: Incumbents publish their own vulnerabilities every year in SEC filings. The insight is public; the execution is what most people skip. (SEC Regulation S-K, Item 1A; Christensen, The Innovator's Dilemma, 1997)

The three thresholds in order:

1. Comprehension threshold: you can predict who buys and why. Around five to fifteen real customers is enough to clear this.
2. Viability threshold: revenue covers your minimum. The maths are specific to your situation, but you must be able to run them.
3. Growth threshold: you can acquire customers faster than you lose them.

The order is strict. Each one gates the next. This is not just a question of whether it is worth building. The thresholds give you a framework for knowing when to stop, pivot, or double down.

If you cannot clear a threshold, the diagnosis is different each time:

• If you cannot hit comprehension, the problem is not real enough or specific enough. Stop or reframe.
• If you cannot hit viability, the pricing is wrong, the market is too small, or you are the wrong person to sell it. Fix one or stop.
• If you cannot hit growth, it is a distribution problem: the thing works but spreading it is broken. That is actually the most solvable of the three.

Write down the names of five specific people who would buy your product and what exactly would make them pay. If you cannot do that, you have not cleared the comprehension threshold, and viability is unknowable.

Figure: 74% — High-growth startup failures caused by premature scaling, growing before comprehension and viability are validated (Startup Genome Report, 2012)

Myth: Checking whether a business is viable is the first step before building
Reality: Viability cannot be known until comprehension is clear. You must know who buys and why before you can know what they will pay. (Blank, The Four Steps to the Epiphany, 2005)

1. How are we sourcing our inputs more strategically? Are we addressing the real supply and demand imbalance that is inflating our costs?
2. How are we making the work more sustainable? What disruptions are we experiencing and are we adapting to them or assuming they are temporary?
3. How are we using our energy more efficiently? Are transformation costs high because we are building the wrong things or building things the wrong way?

These questions do not produce post-its. They produce paragraphs, which means they require thought, which means the meeting starts with substance rather than raw brainstorm output.

Replace stop/start/continue with three written questions sent before the meeting: how to source more strategically, how to make the work more sustainable, and how to use energy more efficiently. Require paragraphs, not post-its.

Figure: 20% — Fewer unique ideas generated by brainstorming groups versus the same number of individuals working alone (Mullen, Johnson & Salas, Psychological Bulletin, 1991)

Myth: Brainstorming with post-its surfaces the team's best thinking
Reality: Groups brainstorming together generate 20% fewer unique ideas than individuals working alone. The format suppresses the quality it claims to unlock. (Mullen, Johnson & Salas, Psychological Bulletin, 1991)

• Will it measurably increase development speed?
• Will it reduce the number of critical bugs that currently have no workaround?

If the answer is yes to either, the work is likely justified. If the answer is no on both counts, meaning the codebase will feel cleaner but ship at the same rate with the same failure modes, then what is being proposed is not delivery. It is comfort.

Before you start any refactoring, write down two things: how it will increase development speed and how it will reduce critical bugs with no workaround. If you cannot fill in either blank, it is not delivery.

Figure: 42% — Developer time spent on technical debt rather than new features (CAST Research Labs, 2021)

Myth: Refactoring is always a good investment in the codebase
Reality: Refactoring that doesn't measurably speed up development or eliminate critical bugs is an illusion of progress. It feels like work but ships nothing. (CAST Research Labs, 2021)

The test is behavioral, not attitudinal. When a prospect says 'that's interesting' instead of 'how soon can I have it,' they have already filed your product under 'things I would not mention in a meeting.' Interesting means unspoken. You can run the same test in reverse: would your target customer mention using your product in a work meeting without hesitation? If the answer is no, word-of-mouth is structurally unavailable to you. Not slow, not blocked, not fixable with better marketing. Structurally unavailable.

The exception is real but narrow. Some products solve embarrassing problems and still scale through paid acquisition plus unusually strong retention economics (think anonymous communities or therapeutic apps that converted stigma into a badge via reframing). Headspace did this deliberately: meditation was hippie-adjacent until they repositioned it as a high-performer productivity habit. The problem did not change; the framing made it safe to admit. That path exists, but it requires reframing the problem statement, not just the product.

Contrast this with the failure mode that looks safe: a product with a respectable, mentionable value proposition that is too niche to come up naturally in conversation. A B2B tool for one narrow compliance workflow passes the embarrassment test and still dies quietly, because nobody thinks to mention it. There is no moment where recommending it makes the recommender look good or feel generous. Admissibility is necessary but not sufficient.

When you fail the work-meeting test, you have three choices, and the honest answer determines which runway math applies:

1. Reframe the problem statement. Quote customers admitting it in their own words: on your landing page, in your pitch, in onboarding. If enough say it privately, someone will say it publicly.
2. Change the target customer. Find the segment where the same problem is public: the person who talks openly about what your current customers hide.
3. Accept paid-only and build accordingly. High LTV, low churn, sustainable CAC makes it a business. Without those, it is a treadmill.

Ask whether your target customer would mention using your product in a work meeting without hesitation. If not: reframe the problem statement, change who you sell to, or accept paid-only growth and build your unit economics around it.

Figure: 42% — Startups that fail due to 'no market need'. A significant fraction are solving real problems customers won't admit publicly, not absent ones. (CB Insights, The Top 12 Reasons Startups Fail, 2021)

Myth: Our retention proves the problem is real and growth will come eventually
Reality: Retention and referrals are independent. A product people use privately and never mention can have excellent retention and zero organic growth simultaneously. (CB Insights, 2021; Berger, Contagious, 2013)

• smart
• successful
• well-travelled

Jonah Berger's research into why things go viral found that products with high social currency spread around 2.4 times faster than functionally identical alternatives that carry no status signal. The design implication is deliberate: make your product something buyers are proud to be associated with, and they will do your marketing for free. The question is not whether your product works. It is whether the act of using it says something good about the person using it.

Ask one question before finalising your product's positioning: would a customer post about buying this unprompted? If not, ask what would need to change for them to want to.

Figure: 2.4× — Speed at which products with high social currency spread versus functionally identical alternatives (Berger, Contagious, 2013)

Myth: Quality speaks for itself and a good product doesn't need social signalling
Reality: Products that make buyers look good spread 2.4x faster. Status is a distribution channel, not a vanity metric. (Berger, Contagious, 2013)

• rewards both sides
• removes friction from the act of sharing
• ties the reward to the core value of the product (storage, in Dropbox's case)

If your product has a referral mechanism, it should feel like a natural extension of using the product, not a loyalty programme bolted on as an afterthought. Design the incentive before you design the ad.

Add a referral mechanism that rewards both parties with the core value of the product, not a generic discount, before you spend anything on advertising.

Figure: 3,900% — Dropbox user growth in 15 months after launching its referral programme (Drew Houston, Dropbox Blog, 2010)

Myth: Good products spread on their own and great work doesn't need referral programmes
Reality: Dropbox grew 3,900% by designing the incentive to share. Organic virality is rare; structured referrals are not. (Drew Houston, Dropbox Blog, 2010)

• a jingle
• a tagline
• a mascot

The more you compress a message without losing its meaning, the more likely someone is to repeat it correctly to someone else. George Miller's 1956 research on working memory established that the human brain can hold around seven items at once, which means every word you add to a message competes with every other word for a slot that was already full. The same principle applies to product naming, onboarding copy, and pitch decks: if the person you are talking to cannot explain your product to a colleague in thirty seconds, your marketing has not done its job. Cut until there is nothing left to cut, then check whether what remains is still true and still interesting.

Write down your product's value proposition. If it takes more than one sentence and thirty seconds to say aloud, cut it until it does. Then test whether someone who heard it once can repeat it correctly.

Figure: 7 — Average number of brand exposures needed before a consumer remembers a message (Marketing Rule of Seven; Lant, 1985)

Myth: More information makes marketing more persuasive
Reality: The brain remembers what it can repeat. Long, complex messages are forgotten; short, sticky ones spread. (Miller, Psychological Review, 1956; Lant, 1985)

• Would a doctor recommend it to a patient?
• Would an employee bring it up in a team meeting without hesitation?

If the answer is no, the growth channel is blocked at the source. Removing the social risk of recommending is as important as making the product worth recommending in the first place.

Audit your product for social risk: would a doctor recommend it to a patient, or would an employee bring it up in a team meeting? If not, fix what makes it risky to endorse before spending on acquisition.

Figure: 83% — Consumers who trust recommendations from people they know above all other channels (Nielsen Global Trust in Advertising, 2015)

Myth: Controversial products generate the most word-of-mouth
Reality: 83% of purchase decisions are influenced by trusted recommendations. People only recommend things they're comfortable defending. (Nielsen Global Trust in Advertising, 2015)

• settings
• preferences
• saved history

or implicit, where the app learns your patterns without asking. If privacy is a concern, all of it can be stored locally on the user's device rather than on a server. The personalisation works the same way, and the user keeps control of their data. But the underlying mechanism is the same: the more the product reflects your identity and behaviour back at you, the more expensive it becomes to switch away from it. You have not just invested time in the product; the product has invested in you. The practical version of this for any product is to find the one moment where a user thinks 'this thing gets me', like a playlist that feels curated for you, a recommendation that seems to read your mind. Design everything around creating that moment as early as possible.

Find the one moment in your product where a user thinks 'this gets me', then redesign onboarding to deliver that moment in the first session, not the fifth.

Figure: 80% — Share of Netflix content watched driven by its personalisation algorithm, not search or browsing (Netflix Technology Blog)

Myth: Retention comes from habit loops and push notifications
Reality: The stickiest products feel like they know you. Netflix's algorithm drives 80% of what users watch, not search or the new releases section. (Netflix Technology Blog)

• Does any other feature depend on this one? If not, it is non-critical.
• Is there another way to get the same result without building this? If yes, there is a workaround.

A feature that is non-critical and has a workaround is a candidate for removal, not because it is useless, but because its absence costs nothing and its presence costs engineering time, maintenance, edge cases, documentation, and bugs. Run the analysis, rank by severity, remove from the bottom up, and stop when removing anything would actually break something. What remains is the minimum viable product in the literal sense: the smallest set of features where every one is load-bearing.

List every planned feature, mark which ones other features depend on and which have a workaround, then cut the ones with neither. Do this before you build, not after.

Figure: 64% — Software features that are rarely or never used (Standish Group, Chaos Report)

Myth: More features make a product more valuable
Reality: 64% of software features are rarely or never used. Each one you don't cut adds maintenance cost, complexity, and bugs with no return. (Standish Group, Chaos Report)

• emotional appeals
• us-versus-them framing
• deliberate simplification
• endless repetition

Recognising the mechanism does not make you immune, but it is the starting point. The Stoics recommended daily practice; the Stanford Encyclopedia of Philosophy is a reasonable place to start: plato.stanford.edu/entries/stoicism.

Apply the Stoic dichotomy of control daily: write down what is worrying you, mark what you can act on, and discard the rest. If you stay on X, curate ruthlessly and only follow accounts that give you concrete next steps, not ones that tell you what to fear.

Figure: 1 in 4 — People globally affected by anxiety disorders (WHO)

Myth: Anxiety keeps you alert and on your toes
Reality: Chronic anxiety shrinks the prefrontal cortex, the seat of reasoning, planning, and judgment. (Arnsten, Nature Reviews Neuroscience, 1998)

• output unchanged
• absenteeism down
• reported well-being up

The countries that sleep well did not stumble into it. They wrote it into law and measured the results. The ones that do not have simply not decided to yet.

Set a hard stop time for work and enforce it. If your employer does not respect it, that is a negotiation to have, or a data point about whether to stay.

Figure: 32.2h — Shortest average working week in Europe: the Netherlands (OECD)

Myth: Sleeping less is a sign of dedication and ambition
Reality: 17 hours awake produces the same cognitive impairment as a 0.05% blood alcohol level (Harrison & Horne, Journal of Experimental Psychology, 2000)

• which skills you build next
• whether you are the person who understands the system, or the one waiting to be told what it decided

Pick one skill adjacent to your current role that machines handle poorly (ambiguity, trust, novel judgment) and invest in it deliberately before your queue forces you to.

Figure: 44% — Workers worldwide reporting significant stress daily at work (Gallup, 2023)

Myth: Automation reduces workplace stress by removing tedious tasks
Reality: Global workplace stress has risen in parallel with automation. The anxiety shifts from tasks to existential job security. (Gallup State of the Global Workplace, 2023)

1. Identify the critical tasks you have handed to automation.
2. Periodically turn them off and practice manually.
3. Keep the interval short enough that the skill does not decay.

Not because the machine is unreliable, but because you are, and the only way to stay ready is to keep practicing the skill the machine has been covering for you.

Schedule regular manual practice for any critical task you have automated. The interval should be short enough that the skill does not decay before the next failure.

Figure: 80% — Aviation accidents attributable to human factors (Boeing Statistical Summary)

Myth: More reliable automation makes human operators safer
Reality: High-reliability systems breed complacency. Operators lose manual skill and situational awareness precisely when they need them most. (Parasuraman & Manzey, Human Factors, 2010)

• ambiguous
• high-stakes
• emotionally demanding

The promise was more time; the result was a harder residual. What you can do is stop waiting for automation to sort your queue and instead choose to work on the hard problems before they become the only problems left. The people who will do well are not the ones who avoided difficult work. They are the ones who sought it out early enough to get good at it.

Deliberately take on one hard, ambiguous problem this week instead of waiting for it to become unavoidable. Difficulty practiced early becomes competence; difficulty forced on you late becomes crisis.

Figure: 60% — Occupations with at least 30% of tasks technically automatable (McKinsey Global Institute)

Myth: Automation frees workers for more rewarding, easier work
Reality: It filters out easy tasks. Everything left in the queue is harder, more ambiguous, and higher-stakes than before. (McKinsey Global Institute, 2017)

• the contractor who does not pick up on Fridays
• the IT department that closes tickets in three weeks
• the supplier who decides your order is not worth prioritising

Automation does not introduce dependency; it swaps an unpredictable one for a predictable one. A system that runs your invoicing at midnight on the first of the month does not have a bad day, does not go on holiday, and does not decide it has a better offer. The people who resist automation on the grounds that it creates reliance on machines have not noticed how much reliance on other humans they are already carrying, and how little of it was ever in their control.

List every human in your critical path and ask which could be replaced by a system you control. Start with the one whose unreliability costs you the most.

Figure: 99.99% — AWS SLA uptime: 52 minutes of permitted downtime per year (AWS)

Myth: Automation creates dangerous new dependencies you didn't have before
Reality: You were already dependent on humans who cancel, get sick, and have their own agenda. Automation just makes the dependency predictable. (AWS Shared Responsibility Model)

• roundabouts instead of intersections
• barriers between lanes
• speed limits set by physics rather than optimism

AWS formalised the same logic for cloud infrastructure with its shared responsibility model, which draws a hard line between what the platform guarantees and what the user must handle, so neither side is surprised when something breaks. The worker of the future is less an executor and more a system designer who asks, before anything goes wrong, how bad can this get if someone does the wrong thing, and then makes the answer as small as possible.

For any process you own, ask: if someone does the worst plausible thing, how bad does it get? Then redesign so the answer is recoverable. That question is your new job description.

Figure: -65% — Reduction in Swedish road fatalities since Vision Zero launched in 1997 (Swedish Transport Agency)

Myth: The future of work means working harder alongside smarter machines
Reality: The real job is designing systems that contain the damage when humans, inevitably, make mistakes. (Swedish Transport Administration, Vision Zero)

1. More founders can enter.
2. More companies get built.
3. The net result is more employment, not less.

If you want to start something, focus on reducing your startup cost rather than waiting for a safe market. Automation is the cheapest it has ever been. Use it to lower the floor on what viable looks like.

Figure: 2.5% — Japan's unemployment rate alongside world-leading robot density (Statistics Bureau of Japan)

Myth: Robots destroy more jobs than they create
Reality: Japan, the world's most roboticised major economy, has maintained one of the lowest unemployment rates in the G10 for decades. (International Federation of Robotics)

• a page exists
• how fast it loads
• how many other sites point to it

but it still cannot tell you whether the page is genuinely useful, so it keeps deferring to the crowd, which means the web's most linked pages win regardless of quality, and if you actually made something good you now have to spend your energy chasing backlinks instead of improving the work. A clear example is Wikipedia: it ranks first for almost everything not because it is always the most accurate or deepest source, but because half the internet links to it. Any specialist who writes a better page on the same topic will sit on page four until someone notices them and links back. The part you control is the work itself and where you take it first: publish for a specific audience that already trusts you, send it directly to people who would genuinely find it useful, and let the backlinks follow from that, rather than spending the same energy on SEO for an algorithm that cannot tell the difference anyway.

Send your next piece directly to ten people who would genuinely find it useful. That is more valuable than any SEO optimisation and costs the same amount of time.

Figure: 27.6% — Clicks captured by the top Google result; page two gets less than 1% (Backlinko)

Myth: Better content ranks higher on Google
Reality: Google ranks by backlinks, not quality. The most linked page wins regardless of accuracy or depth. (Brin & Page, PageRank patent, 1998)

• same content
• same time of day
• same platform

one got 340 views while the other got 41,000, which means the outcome was noise, not signal, and every time I opened the app to check I was pulling a lever. Adam Mosseri (Instagram's own head) has publicly admitted the reach variance has 'more to do with user behavior than algorithmic changes,' which means even the person running the platform cannot fully explain why your post lands or disappears. The problem with that for mental health is not the lows. It is the highs, because a random 41,000-view day does not teach you anything useful, it just makes you come back and pull again, and I decided I did not want to spend my attention that way.

Decide before you post what success looks like in terms you control (did you say something true, useful, well-crafted?) and ignore the view count entirely.

Figure: 120× — Difference in views between identical posts, same content, same time of day (Author's data; Adam Mosseri (Head of Instagram): reach shifts are driven by user behaviour he can't fully explain)

Myth: Consistency and quality are rewarded and posting more will make you grow
Reality: Identical posts on the same platform can vary 120x in views. The outcome is noise, not a signal you can optimise. (Author's data; Adam Mosseri admitted Instagram's own reach variance has 'more to do with user behavior than algorithmic changes')

• spare rooms
• idle professional skills
• underutilised relationships
• capital sitting in low-yield accounts

The business is not the asset; the business is the recognition that someone else needs what you already have.

Before you raise money or hire, spend one hour listing underused assets around you (spare capacity, idle skills, underutilised relationships). Then ask which of those has unmet demand. That is your business.

Figure: $75B — Airbnb's market cap, built from three air mattresses already sitting in a closet (Airbnb IPO, 2020)

Myth: You need capital and infrastructure before you can start a business
Reality: Airbnb started by renting floor space they already owned. The asset existed; the business was recognising it had value to someone else. (Brian Chesky, How Airbnb Was Founded)

• lower prices
• wider selection
• faster delivery

That stability meant every dollar invested in logistics infrastructure, warehouse automation, or supplier relationships was compounding certainty, not a gamble on shifting taste. Patrick Collison at Stripe made a related argument for why large businesses are underrated: scale creates the ability to make long-term bets that smaller companies cannot sustain. The discipline is the same in both cases: identify the need that will not shift, then build toward it relentlessly, because the compounding advantage of being right about something stable far exceeds the short-term gain of being first on something uncertain. The practical version is simple: write down the core need your next project serves and ask whether people had it twenty years ago and will have it twenty years from now. If yes to both, you are building on bedrock. If the answer depends on a current trend, you are building on fashion.

Write down the core need your next project serves, then ask: did people have this need 20 years ago, and will they have it 20 years from now? If yes to both, you are building on bedrock. If not, reconsider the foundation.

Figure: 200M+ — Amazon Prime subscribers, built on the bet that customers will always want lower prices, wider selection, faster delivery (Amazon Annual Report, 2021)

Myth: Innovation means chasing what is new and changing
Reality: Amazon's biggest bets (low prices, vast selection, fast delivery) were made on needs that are identical today to what they were in 1994. (Jeff Bezos, Amazon Shareholder Letter, 2012)

1. Make your requirements less dumb. Every requirement has an owner, and that owner is probably wrong about at least one thing, regardless of how smart they are.
2. Delete the part or process entirely. If you are not occasionally adding things back in after deleting too aggressively, you have not deleted enough.
3. Simplify or optimise. Only here, in third position, does the word 'optimise' appear, because optimising a process that should not exist is waste disguised as progress.
4. Accelerate cycle time.
5. Automate.

Musk's own admission is that he has personally made the mistake of going in reverse: automating first, then accelerating, then simplifying, and paid for it. Dara Khosrowshahi at Uber makes the same point from a different angle: when Uber's mobility business lost 85% of its volume overnight at the start of the pandemic, the response was not careful deliberation. It was top-down and fast, because a decision that is twenty percent off but made immediately beats a perfect answer that arrives after the window has closed. The process question and the decisiveness question are the same: are you spending time on things that should not exist?

Before optimizing anything, ask whether it should exist at all. If you cannot justify its existence independently, delete it. Only then simplify, accelerate, and automate, in that order.

Figure: 95% — Reduction in cost per kilogram to orbit: Space Shuttle vs SpaceX Falcon 9 reusable (NASA, SpaceX Commercial Crew Program)

Myth: Optimization is the path to efficiency
Reality: The most common engineering mistake is optimizing something that should not exist. Questioning the requirement is always step one. (Elon Musk, Tesla Shareholder Meeting, 2021)

In 2015 I was converting old desktop websites to mobile responsive because the shift to mobile had made them broken and unusable. Most businesses had not seen it coming. The technical shift happened, the user behavior followed, and suddenly there was a wide-open gap between what existed and what was needed.

WebMCP is doing something structurally similar. It gives browsers a standard way to connect AI agents to tools and data sources without routing everything through a backend server. Agentic AI that browses, fills forms, extracts data, and takes actions can now live entirely in the client. The infrastructure assumption that AI requires a backend is starting to break the same way the assumption that web apps required a desktop did.

What this opens up:

• Privacy-first AI tools that never send user data to a server
• Offline-capable agents that work without a network connection
• Dramatically lower operating costs for AI-powered products
• A new class of browser extensions that are actually intelligent
• Personalized models that run and adapt on the user's own hardware

In 2015 the businesses that moved early on responsive design built a durable advantage. The ones that waited paid someone like me to fix it under pressure later.

I do not know exactly how the agentic browser shift will play out. But I know what it feels like when a platform constraint disappears and the old assumptions stop being true. This feels like that.

Pick one workflow you currently send to a server-side AI API and prototype it running locally in the browser via WebMCP. The constraint will show you where the real opportunity is.

Figure: 2026 — Year browser-native agentic AI via WebMCP became a plausible production architecture, not just a demo (Model Context Protocol specification, Anthropic, 2024; WebMCP project, 2025)

Myth: AI agents need a server to be useful
Reality: WebMCP now lets capable AI agents run entirely in the browser with no server round-trip. The same assumption that said mobile apps needed servers for everything was wrong in 2012 and this one is wrong now. (Model Context Protocol, Anthropic, 2024)

Those are three separate questions with different answers.

The instrument that self-enforces

Most regulatory instruments have a structural defect: they require the state to monitor, enforce, and resist capture. Inspectors can be pressured. Caps can be lobbied upward. Fines can be set below the cost of compliance and treated as a license to continue.

Strict liability with mandatory insurance avoids this entirely. The operator must hold a policy covering the maximum credible loss, written at market rates in a competitive insurance market, with no state subsidy and no liability cap. This instrument does five things at once:

• Prices the externality, not the transaction: the premium tracks expected damage, not activity volume
• Self-enforces: either the operator holds a current policy or they do not
• Builds in adversarial verification: the insurer pays out on harm, so they price it correctly and audit the operator
• Gives the state no fiscal stake in the activity continuing: premiums go to insurers, not the Treasury
• Finances the science: the insurer loses money if the risk model is wrong, so they fund the toxicology, epidemiology, and loss modeling needed to price correctly

If the maximum credible loss exceeds insurance market capacity, no policy is written. The activity stops by the absence of coverage, not by a regulator's decision. The market does the work.

Which jurisdiction should act

Whether unilateral action is sufficient depends on the share of external loss that falls outside the deciding jurisdiction. Three regimes:

• Local externality: contained aquifer contamination, airport noise, landfill leachate within one jurisdiction. Per-country action is optimal; leakage does not apply.
• Trade-coupled externality: deforestation for export markets, factories serving foreign demand. Consumption in A drives harm in B. Border adjustments like the EU CBAM are the correct instrument.
• Transboundary or global externality: shared rivers, greenhouse gases, fishery collapse. Floor near 1: unilateral action captures little. Treaty or coordinated bloc required.

The coordination requirement is not a political preference. It follows from the geometry of the externality. For Cases 1 and 2, unilateral action is sufficient. For Case 3, it is not.

The competitiveness objection

The objection that taxing pollution just sends factories to countries that do not has real bite, but only for Case 3. For Cases 1 and 2, the objection is a category error.

A country applying a local externality brake gains on inclusive wealth even when its GDP share of a dirty industry falls. The World Bank's Changing Wealth of Nations data shows this repeatedly: resource-dependent economies post rising GDP per capita alongside falling per-capita inclusive wealth. They are competitive only on the wrong metric.

For global externalities, the competitiveness objection is not a flaw in the two-condition criterion. It is a coordination problem the criterion correctly identifies. The instrument is right. The jurisdictional scope is insufficient.

The coordination floor function in shouldBreak.js computes the leakage rate from unilateral action given the spatial distribution of external parties across jurisdictions.

When evaluating a policy instrument, check whether it is strict liability with mandatory insurance, and identify which regime applies: local, trade-coupled, or global. Each requires a different instrument and a different jurisdictional scope.

Figure: 70 — Approximate share of global activity a coordinated bloc must cover before leakage from unregulated jurisdictions becomes de minimis for global externalities (Hoel (1994); Carraro & Siniscalco (1993); IPCC AR6 Working Group III, 2022)

Myth: Taxing pollution just sends factories to countries that don't, so the regulation achieves nothing
Reality: The objection only bites for global externalities. For local ones, the regulating country gains on inclusive wealth even as its dirty industry shrinks. For trade-coupled ones, a border adjustment eliminates leakage. (World Bank, The Changing Wealth of Nations, 2021; Nordhaus (2015) on climate clubs)

The bad news is in the shape of the curve.

A power law is steep at low spending levels and flat at high ones. The marginal growth gain from cutting one point of spending is proportional to spending^(-(alpha+1)). With alpha = 1.5, the exponent on the marginal term is 2.5. A country at 20% spending gains roughly (50/20)^2.5 = about 6 times more growth from the same cut than a country at 50%.

Singapore at 15% would gain more still. France at 57% is near the flat end of the curve.

This creates a trap. The cure is real. The payoff is small. The disruption is large. That combination is what makes it politically impossible to cut.

Three paths out:

• Cut fast and deep: a large one-shot consolidation (10+ points) moves the country to a steeper part of the curve. Canada cut roughly 10 points in three years in 1995-1997.
• Hold spending flat and let GDP growth do it. The ratio falls by about 2% per year as a proportion when real GDP grows at 2%. This is the Sweden post-1993 playbook, and it took 15 years.
• Do nothing. The ratio stays high. Growth drag compounds. Debt rises. Future cuts become more expensive.

The math on the slow path is brutal.

France currently spends around 57% of GDP. At 0% real spending growth and 1.5% real GDP growth (optimistic for France's recent record), the spending-to-GDP ratio falls by about 1.48% per year as a proportion of its current level. To reach 30% takes roughly 45 years. To reach 20% takes over 90.

Canada and Sweden succeeded because they combined spending freezes with structural reforms that pushed real GDP growth above 2%. France has not done either.

The conclusion from the model is uncomfortable. Incremental annual cuts of 0.5 to 1 point are arithmetically real but economically invisible. They do not move the country far enough along the power law curve to produce a detectable growth response in a political cycle.

Cut fast, or wait 40 years. There is no comfortable middle path that produces visible results.

When evaluating a fiscal consolidation plan, ask how many percentage points it moves spending and over how many years. A 1-point cut over 10 years in a high-spending country is noise. A 10-point cut in five years is signal.

Figure: 6x — Times more growth a country at 20% spending gains from a 1-point cut compared to a country at 50%, derived from the power law fit with alpha=1.5 (Derived from cross-country power law fit, World Bank data 2005-2023)

Myth: Cutting 5 points of public spending delivers roughly 5 points worth of growth improvement
Reality: The power law is steep at low spending and flat at high spending. The same cut delivers six times less growth improvement at 50% than at 20%. France is on the flat part of the curve. (Power law model, R2=0.42, World Bank cross-country data 2005-2023)

The data does not support a sweet spot.

Cross-country World Bank data from 113 countries over 2005-2023 fits a power law better than any quadratic. R2=0.42 for the monotonically decreasing power law versus R2=0.39 for the traditional Armey curve. The relationship is not U-shaped. It just goes down.

Some reference points:

• Singapore: government spending around 15% of GDP, persistent above-average growth over decades
• Bangladesh: around 9%, one of the fastest-growing economies of the past two decades
• South Korea built its high-growth phase with government under 20%
• High-spending OECD economies consistently underperform on growth relative to their income level

No sweet spot appears at 20%, 25%, or 30%. The curve keeps falling.

This answers how much but not on what. If spending reliably slows growth, the question becomes when the brake is worth pulling.

Two conditions must both be met for an intervention to be justified.

First, the activity must impose a net wealth loss on external parties (people who bear cost without being participants in the transaction), summed across all capital kinds: produced, human, natural, knowledge, and institutional. A factory that poisons a river fails this test. A business that outcompetes a rival does not, because the rival was a voluntary participant in the market.

Second, the intervention must be cost-effective: the deadweight loss from the regulation, plus enforcement cost, plus the probability of regulatory capture multiplied by its expected damage, must be less than the external wealth loss it prevents. A regulation that costs more to enforce than the harm it stops fails this test even if the harm is real.

Activities that satisfy both conditions are genuine negative externalities:

• Pollution that degrades shared resources beyond self-repair rates
• Resource extraction that exceeds regeneration, destroying future productive capacity
• Systemic financial risk, where institutions privatize gains and socialize losses

Activities that fail one or both conditions (licensing requirements that protect incumbents, subsidies that redirect investment without correcting a price signal, spending programs that transfer wealth without addressing an external cost) slow growth without a welfare justification.

The two-condition test does not require a macroeconomic model. It requires identifying who is bearing cost they did not choose to bear, across what kinds of capital, and whether the intervention is cheaper than the damage it prevents.

The formal criterion is implemented in shouldBreak.js, including the certainty-equivalent pricing rule, the trustworthiness gate, and the required insurance coverage calculation.

Before supporting any policy, apply two tests: does it reduce a net wealth loss imposed on external parties across all capital types, and is the intervention cost-effective? If both are not clearly yes, the policy is likely slowing growth without justification.

Figure: 0.42 — R-squared for the power law fit between government spending share and GDP growth across 113 countries (2005-2023). The quadratic Armey Curve fits at R2=0.39. (World Bank national accounts data, 2005-2023)

Myth: There is an optimal government size around 20-30% of GDP where spending maximizes economic growth
Reality: Cross-country data fits a monotonically decreasing power law, not an inverted U. No sweet spot appears at 20%, 25%, or 30%. The relationship just falls as government grows. (World Bank, cross-country GDP and expenditure data, 2005-2023)

This is not a bug. The new build includes explicit text telling users that web apps will now open from the default browser. That is a product decision.

I have been here before.

In 2019 Google banned Love Score from the Play Store. The app had no internet connection. It processed SMS metadata entirely on device. It sent nothing anywhere. Google banned it anyway because it accessed a sensitive data category. The technical reality did not matter. The category did.

Apple is doing something structurally similar. The stated reason is compliance with the EU Digital Markets Act, which requires Apple to allow alternative browser engines. Because PWAs on iOS have always depended on WebKit, Apple is claiming it cannot safely support them under the new rules. Critics are calling this malicious compliance: using a consumer-protection law as cover for removing capabilities that compete with the App Store.

The pattern is the same:

• Platform sets rules that serve its own interests
• Developer builds something useful within those rules
• Platform changes rules when those interests shift
• Developer's work is removed, degraded, or blocked
• No warning, no timeline, no appeal

What the web being "open" actually means: the protocols are open. The runtime is not. Apple controls what APIs Safari exposes on iPhone. Google controls Chrome. Mozilla controls Firefox. Each of them can restrict what your web app can do and the constraints can change at any time without notice.

The platform is never neutral. It is controlled by a company with its own revenue model. The web reduces the number of gatekeepers but it does not eliminate them. The lesson from Love Score was not specific to app stores. It was about any runtime owned by a party whose interests can diverge from yours.

If you are building something that depends on a capability a large platform controls, that dependency is a risk. Not a theoretical one.

Before building on any platform, including the browser, map which companies control the runtime and what incentive they have to restrict your access. The web is not neutral by default.

Figure: 2008 — Year Apple first launched web app capabilities on iPhone, sixteen years before quietly removing them in EU markets under iOS 17.4 (Mashable, Apple looks to be killing web app capabilities, February 2024)

Myth: The web is an open platform no single company can control
Reality: Apple controls which web APIs are available on iPhone Safari. In February 2024 it removed PWA capabilities and push notification support for EU users, wiping app data in the process. No announcement. No timeline. Just a beta that changed the rules. (Mashable, Apple looks to be killing web app capabilities, February 2024; 9to5Mac, iOS 17.4 web app EU, February 2024)

This is not a new observation. FMEA was standardized by the US military in 1949 and remains the dominant structured failure framework. It asks: what can fail, how severe, how likely. But it starts at the failure mode, not the doctrine upstream of it. That upstream layer, who has authority to define what the right belief even is for a given role, is a governance problem, not a data problem. Williams (2017, PMJ) found the same gap in practice: risk registers list risks in isolation and fail to capture causal chains. Recovery plans treat symptoms without touching the doctrine that produced them. Olivier and Schwella (2018) measured that organizations lose 49.6% of strategic potential in the gap between intent and execution, not because the strategy was wrong, but because no one named the drift.

That omission matters because a hospital, a court, a sales department, and an engineering workshop do not fail in the same content. But they do fail in the same structure. A false doctrine produces the wrong attribute in the deliverable, the wrong attribute generates risk, the risk causes consequences, and recovery has to be specified at both the risk and consequence layer.

In this register, every row uses the same anatomy:

• environment and role
• bad quality and good quality
• false doctrine and true doctrine
• actions and deliverable
• wrong attribute and right attribute
• active and passive countermeasures
• external and internal risks
• external and internal consequences
• recovery paths for each risk and consequence

The important column is `false_doctrine`. That is the alignment failure. In a doctor's office it may be charlatanism. In regulation it may be cronyism. In an engineering workshop it may be absurdism. The doctrine changes by sphere, but the structural path from misalignment to damage does not. The names themselves are imperfect and can be disputed. Take them as starting points for thinking, not as verdicts. The value is in the structure, not in whether charlatanism is the exact right word for a given failure mode.

That structural focus is also what makes this a generative framework rather than a descriptive one. A descriptive register catalogues the domains it has already seen; it is a lookup table. This structure is a grammar. Take a context that appears nowhere in the example dataset: a maritime port authority, a hospice care team, a satellite launch crew. The structure still applies: there is a role, a deliverable, an attribute that can drift, a doctrine behind the drift, countermeasures, consequences, and recovery paths. You do not retrieve those entries from the dataset; you derive them from the anatomy. The columns constrain what a valid entry looks like, and that constraint is what makes the output meaningful even for domains no one has catalogued yet.

That property has a direct implication for AI. A model fine-tuned on this structure would be unusually good at two questions that current systems handle poorly: what is the upstream cause of this failure, and what is the appropriate recovery given this consequence. Those are not retrieval questions. They require reasoning along the causal chain from doctrine to attribute to risk to consequence to recovery. The register makes that chain explicit in every row, which means the training signal is not just labelled examples but labelled reasoning paths. That is directly useful for AI systems that need to diagnose and correct their own behaviour, rather than merely pattern-match against past errors.

The useful move is to instrument the gap between the wrong and right attribute for each deliverable you care about. Once that gap is explicit, the countermeasures, risks, and recovery plans stop being abstract policy language and become design decisions.

The example dataset linked here was handcrafted over two years to see how far the framework could go. Thirty spheres, five roles each, every column filled. The answer is: pretty far. The structure held across domains that share nothing in surface content (from military logistics to spiritual communities to corporate legal) because the anatomy underneath them is the same.

If you want to use this approach, start with one context you actually own:

• Name the role.
• Name the deliverable.
• Define the wrong and right attribute.
• Write the false doctrine that causes the wrong one.
• Add one active and one passive countermeasure.
• Write the recovery path before the failure happens.

If you cannot name the false doctrine in your domain, you do not yet know what alignment failure looks like there.

Name the role, the deliverable, the wrong and right attribute, the false and true doctrine, and the recovery path. If you cannot fill all six, your risk register is too vague to govern action.

Figure: 49.6% — Share of strategic potential lost during execution due to misalignment between intent and action, measured across public sector organizations (Olivier & Schwella, International Journal of Public Leadership, 2018)

Myth: A risk register only needs to list what can go wrong
Reality: Before you can list risks, you need a structural definition of what failure means in that context. The register makes doctrine, attributes, countermeasures, consequences, and recoveries explicit in the same order for every domain. (Author's risk register, 2022)

The mechanism is different from GANs. Instead of a generator fighting a discriminator, diffusion models learn a single function: given a slightly noisy version of a real image, predict what the noise is. Run that prediction in reverse, starting from pure noise, and you get an image. The key insight is that this process is stable to train and easy to condition on text, which GANs were not.

What GANs failed at, diffusion models fix:

• mode collapse: GANs learned to produce outputs that fooled the discriminator rather than covering the full distribution of real images
• training instability: GANs required careful hyperparameter tuning to converge at all
• text conditioning: steering a GAN toward a specific prompt was architecturally awkward

The practical consequence is that the quality ceiling has moved. These are outputs from a single afternoon of running the model.

On August 9th I asked a Discord bot to generate the official portrait of the definitive winner of the 2022 French presidential election. It produced Macron's face embedded in a baguette, wearing a gold crown. The image is absurd, but the prompt was understood. The model made a political prediction, pulled Macron's face from its training data, and rendered a portrait that is surreal but recognizable. That combination, world knowledge plus image generation plus prompt following, did not exist two years ago.

Video is the obvious next step and the timeline is shorter than it looks. A video is a sequence of image frames. The same denoising process applies in the time dimension as well as the spatial dimensions. Both clips below were generated in 2021. The quality is low and the duration is short, but the structure of the problem is solved. What remains is compute and scale.

Compute costs fall on a predictable curve. The images that require hours on a high-end GPU in 2021 will require seconds on a consumer device in 2025. Video will follow the same curve with a two to three year lag. By 2024 or 2025, generating a ten-second video clip from a text description will be as accessible as generating an image is today.

The implication that gets the least attention is not about creativity or art or jobs. It is about evidence. When any image or video can be generated from a text description, a video of an event no longer proves the event happened. The tools for generating synthetic media are already ahead of the tools for detecting it, and that gap will not close quickly.

Learn to spot diffusion model outputs now: look for unnatural texture tiling, impossible hand geometry, and lighting that has no consistent source. These tells are identifiable today and will weaken over time, so train the eye before you need it.

Figure: 2.97 — FID score achieved by guided diffusion on ImageNet 256x256 in 2021, beating the best GAN score of 3.87 for the first time (Dhariwal & Nichol, Diffusion Models Beat GANs on Image Synthesis, NeurIPS 2021)

Myth: AI-generated images are obviously artificial and video generation is decades away
Reality: Diffusion models produce photorealistic images from text prompts in 2021. The same denoising process applies to video frames; compute cost is the only remaining barrier, and that falls on a predictable curve. (Dhariwal & Nichol, NeurIPS 2021; DALL-E, OpenAI, January 2021)

Not the virus. The virus is real. I am not talking about whether the restrictions were justified. I am talking about what happens to a person when the expectations of daily life shift so completely that they stop noticing what they have given up.

People stopped making plans. Stopped expecting to see their friends. Stopped expecting to work in the same room as their colleagues, to eat in a restaurant without guilt, to travel without a calculation of whether it was essential enough. People wore facemasks in public swimming pools. After a few months, the absence of these things stopped feeling like a loss and started feeling like how things simply are.

That is the part that worries me.

When everyone around you is behaving in a certain way, the social cost of not behaving that way rises fast. You do not have to believe the behavior is correct. You just have to not want to pay the cost of being the person who is still acting normally. So you stop acting normally too. And then normal becomes something you can barely remember having expected.

Vaclav Havel described this mechanism in 1979 in The Power of the Powerless. He was writing about life under communist Czechoslovakia, but the structure is the same. His greengrocer puts up a slogan in the shop window not because he believes it but because not putting it up would mark him as different, would cost him something. The ideology is not primarily transmitted by persuasion. It is transmitted by the accumulated cost of non-compliance.

What I find useful in Havel is that his response is not confrontation. It is living in truth. Just continuing to behave as if the normal things are still worth expecting:

• Keep making plans, even when they fall through
• Keep expecting to see people in person
• Keep applying the same standards to arguments you applied before the crisis

This is not denial. It is the refusal to let a temporary emergency become a permanent baseline.

The video below is a year of COVID media in ten minutes.

What made this harder was that the fear was not purely organic. In March 2020 the UK government's behavioural science group SPI-B recommended increasing the perceived level of personal threat via hard-hitting emotional messaging. Governments spent over a billion dollars on pro-compliance campaigns. In April 2021 the New York Times reported that EU Commission President Ursula von der Leyen had exchanged personal text messages with Pfizer CEO Albert Bourla to negotiate the EU vaccine deal. The messages were never produced. The EU ombudsman found the Commission's refusal to disclose them constituted maladministration. Media had its own incentives: fear-driven stories produce clicks, and pharma was already the largest TV advertiser before 2020.

When collective pressure asks you to abandon your standards, habits, or judgment, ask whether the pressure comes from evidence or from the social cost of standing apart. You can acknowledge a real threat without adopting every behavior the panic produces.

Figure: 1979 — Year Vaclav Havel wrote The Power of the Powerless, arguing that individuals can resist a system not by confronting it but by refusing to live within its lies (Havel, The Power of the Powerless, 1979)

Myth: If everyone around you is behaving differently, you must be the one who is wrong
Reality: Collective behavior during a panic is not evidence of collective correctness. Havel described a greengrocer who displays a party slogan not because he believes it but because not displaying it would cost him too much. Conformity and truth are different things. (Havel, The Power of the Powerless, 1979)

The room was not impressed. The pushback was consistent and confident:

• load balancing is an unsolved problem and the training will collapse
• you cannot backpropagate cleanly through a discrete routing decision
• the communication overhead between experts on different devices will eat the compute savings
• it is a clever trick, not a scalable architecture

The people saying this were not uninformed. They had read the papers. They understood the implementation challenges. The instability of early MoE training was real. The load balancing problem was real. The routing collapse problem was real.

What the pushback missed was the direction of travel. Every objection was a solved engineering problem dressed up as a fundamental architectural limit. Load balancing: Shazeer et al. already proposed an auxiliary loss term in 2017 that penalises uneven expert utilisation. Discrete routing gradient: the same paper showed that a noisy top-k gating function is differentiable enough to train. Communication overhead: it shrinks as hardware interconnects improve, and the parameter efficiency of MoE outpaces the overhead at scale.

The Lex Fridman Discord sessions were useful precisely because the disagreement was public and fast. You could watch someone state a confident objection and then watch someone else point to a sentence in the paper that answered it. The people pushing hardest against MoE in those sessions were doing so from a prior that dense transformers were the correct inductive bias for language. That prior was wrong, or at least not obviously right. The paper that would prove it conclusively, Switch Transformers by Fedus, Zoph and Shazeer, had not been submitted yet. It would appear on arXiv in January 2021. We were arguing about an idea whose vindication was six months away and nobody in the room knew it.

MoE is now the architecture behind some of the largest deployed models. The routing problem turned out to be tractable. The objections from those sessions were accurate descriptions of hard problems. What they got wrong was treating hard as impossible.

The pattern is worth naming because it repeats:

1. A new architectural idea surfaces with real implementation problems
2. The problems are treated as evidence the idea is wrong rather than evidence the idea is hard
3. The people closest to the current paradigm push back hardest
4. The implementation problems get solved by people who believed the idea was worth solving
5. The idea is adopted widely and the pushback is forgotten

Attention was called slow and memory-inefficient before it became the default. Transformers were called a brute-force approach with no inductive bias before they replaced everything else. The Kaplan scaling laws paper came out three months ago and people are still arguing about whether they mean anything. None of those objections were stupid. They were accurate descriptions of real problems. What they got wrong was the conclusion.

When a research idea is being dismissed loudly, read the original paper yourself instead of relying on the dismissal. The people pushing hardest against an idea are often the ones who feel most threatened by what it would mean if it worked.

Figure: 128 — Number of experts used in the sparsely-gated MoE layer proposed by Shazeer et al. in 2017, which outperformed dense LSTM models at lower compute cost per token (Shazeer et al., Outrageously Large Neural Networks, ICLR 2017)

Myth: Mixture-of-Experts routing is a clever trick that will never scale to real language models
Reality: Every objection raised against MoE in 2020 is an engineering problem with a known partial solution in the 2017 Shazeer paper. Calling an unsolved engineering problem a theoretical dead end is a category error. (Shazeer et al., Outrageously Large Neural Networks, ICLR 2017)

The distinction matters because the paths to those two achievements are completely different.

Lilienthal's approach was iterative failure. Fly, crash, adjust, fly again. His aerodynamic tables, published in 1889, were the best data available on lift and drag for curved surfaces. Every serious aviation experimenter of the era used them, including the Wrights initially.

In 1900 and 1901, Wilbur and Orville built gliders using Lilienthal's tables. The gliders underperformed badly. Instead of flying more gliders and crashing more often, they stopped.

They built a wind tunnel.

It was six feet long, made of wood, powered by a fan. Between September and December 1901 they tested over 200 wing surface variations and studied around 45 shapes in detail. They discovered that Lilienthal's lift coefficient was off by a factor of roughly two. The tables that every other experimenter was trusting were systematically wrong.

With corrected data, they built a new glider in 1902 that performed exactly as predicted. Then they built the Flyer. On December 17, 1903, it worked on the first attempt.

This is the part the failure-analysis narrative misses entirely. The Wrights did not succeed because they crashed a thousand times and learned from each crash. They succeeded because they found a way to test their assumptions without crashing at all. The wind tunnel let them run controlled experiments where the only variable was wing shape. The crashes were someone else's data collection method.

You do not learn to fly by crashing planes. You learn by building an instrument that lets you isolate variables and accumulate small, verified wins before the first real test.

The pattern is general:

• Test assumptions in a controlled environment before exposing them to real-world noise
• Treat existing data as a hypothesis, not a foundation
• Design experiments where failure is cheap and the signal is clean
• Aim to succeed on the first real attempt because everything before it was already a test

Failure is not the teacher. Controlled experiments are. Failure is just what happens when you skip them.

Before running a live experiment, ask what you can test in a controlled environment that eliminates confounding variables. Build the instrument first. Crash the simulation, not the plane.

Figure: 200+ — Wing surface variations tested by the Wright brothers in their homemade wind tunnel between September and December 1901, before building a single aircraft (Jakab, Visions of a Flying Machine, Smithsonian Institution Press, 1990)

Myth: The Wright brothers invented flight
Reality: Otto Lilienthal had already flown gliders. The Wrights invented controlled flight by building a wind tunnel, finding Lilienthal's tables were wrong, then testing 200 wing shapes before ever attempting a powered aircraft. (Jakab, Visions of a Flying Machine, Smithsonian Institution Press, 1990)

Thomas Jannaud and I built it in 2014. It reads SMS metadata (who you message, how often, in which direction) and plots your contacts on a two-axis chart of balance and passion. No message content. No server. No account. Everything ran on the device.

The app had no internet permission in the manifest. It could not have sent data anywhere even if we had wanted it to. The analysis was local. The output was local. Nothing left the phone.

Google banned it anyway. The reason was that it accessed SMS data.

Not that it misused it. Not that it transmitted it. Not that it violated any specific user's privacy. The category of data was sufficient.

What this makes clear:

• Platform policies are written around categories, not behaviors. "Accesses SMS" is a category. What you do with that access is irrelevant to enforcement.
• Being technically harmless is not a defense. The policy is not about harm. It is about liability surface for the platform.
• On-device processing does not protect you from platform rules. The distinction between local and server-side matters to engineers. It does not map onto platform policy language.
• There is no appeals process that a small developer can meaningfully engage with. The ban is the decision.
• If your product depends on a data category a platform considers sensitive, you should assume access can be revoked at any time regardless of how you use it.

I am not angry about it. The decision is consistent with how large platforms manage risk. They do not have the capacity to audit intent or implementation for every app. They draw broad lines and enforce them uniformly.

But it is worth being clear about what happened: a privacy-respecting app with no network access was removed for accessing a sensitive data category. The fact that it was doing so in the most privacy-preserving way possible was not part of the evaluation.

Before building on a platform, map every policy that could shut you down regardless of whether your app is actually harmful. Platform rules are written broadly and enforced bluntly.

Figure: 0 — Internet permissions requested by Love Score: the app had no network access and processed everything locally on the device (Love Score Android manifest, 2014)

Myth: If your app does not share data with anyone, it cannot be penalized for privacy violations
Reality: Google banned Love Score despite it having no internet connection and sending no data anywhere. The policy was triggered by the category of data accessed, not by what was done with it. (Google Play Store policy enforcement, 2019)

I am not applying.

The program has a real track record. Airbnb, Stripe, Dropbox, Reddit. The network is genuinely useful. The application process forces clarity. None of that is in dispute.

What changed my mind was spending a week reading the YC community forums.

In thread after thread I watched the same dynamic: someone posts a contrarian view, a chorus of polite disapproval follows, and the person softens their position or disappears. Not because they were wrong. Because the social cost of holding the position had become higher than the benefit of being right.

This is what happens to any community that attracts ambitious people who also care deeply about how they are perceived by other ambitious people. The result is performative consensus: everyone signals the approved views, the approved views drift further over time, and the community mistakes conformity for wisdom.

The specific patterns I kept seeing:

• Hiring questions answered primarily through a lens of representation metrics rather than competency
• Criticism of founders redirected toward systemic factors based on who the founder was
• Products evaluated partly on whether they served approved social goals
• Counterarguments to the above met with social disapproval rather than engagement

None of this makes YC a bad accelerator. It makes it a community with a strong implicit culture. Strong implicit cultures are fine if they match how you think. They are a tax on independent reasoning if they do not.

I think better when I am not managing what I say. The forum told me I would be managing it constantly. I will build without that constraint.

Before joining any accelerator or community, read its forums for a week. The norms people enforce in low-stakes discussions reveal the pressure you will face in high-stakes ones.

Figure: 1,500+ — YCombinator portfolio companies by 2018, each shaped by a program culture visible in the forums before you apply (YCombinator, About page, 2018)

Myth: Elite accelerators select purely on founder quality and product potential
Reality: Selection also filters for cultural conformity. The forums reveal the implicit norms before you apply. That signal is free and most applicants ignore it. (YCombinator community forums, 2018)

The idea I am working on: a trusted map of all events, past, current, and future. Not another aggregator. Not a scraper wrapped in a calendar UI. Something structurally different.

The problem with every events product I have seen is that it treats "is this event real?" as a content moderation problem. Someone submits an event. A human reviews it or a filter catches obvious spam. The event appears or does not.

That model does not scale. It also hides the real question: who thinks someone is an authority to say "this event is real, this one is not," and why?

That is the product. Not the events. The graph of trust around events.

Every event claim comes from a source. That source has a history: how often it has been right, how often wrong, what types of events it covers, what its incentive structure is. A venue announcing its own show has a different reliability profile than a local press outlet covering regional culture, which has a different profile than a government tourism board publishing its annual calendar.

None of those sources are binary. They are not trustworthy or untrustworthy. They are trustworthy to a calculable degree, in a specific domain, over a specific time horizon.

The vision:

• Ingest event claims from every source we can reach.
• Model each source as a node with a trust score, domain coverage, and track record.
• Propagate uncertainty through the graph: corroboration raises confidence, silence or contradiction from high-trust sources keeps it flagged.
• Surface not just the event but the confidence level and the reason for it.

At scale, this becomes something no events product has been: an honest index. Not "here are the events" but "here are the events we are confident about, here is why, and here is what we are uncertain about."

The hard problem is bootstrapping the trust graph. You need historical data to score sources, and you need source scores to validate historical data. The exit from that loop is starting with sources that are already publicly auditable: official government calendars, verified venue feeds, press archives with timestamps. You score those first, then use them as anchors to evaluate everything else.

I do not know yet if this is a business. I know it is the right structure for the problem.

Before building a directory or index, answer one question: who is your authority source and how do you quantify how much to trust them? If you cannot answer it, your data will rot the moment it scales.

Figure: 4.7M — Events created on Eventbrite in 2018 alone, each needing someone to decide if it was real, with no shared authority model to make that call (Eventbrite S-1 filing, September 2018)

Myth: A complete events database is a data problem, solved by scraping more sources
Reality: It is a trust problem. More sources without a model of authority produces more noise, not more accuracy. (First-principles reasoning)

A pipeline cannot learn. It processes input and emits output, but has no mechanism to update its processing based on what the output reveals about the input. Only a cycle can do this. The buffers absorb imperfections that would otherwise cascade; the processing modules translate between representational forms.

Each processing module operates within one of three domains:

The three domains are not separable in practice. Any real interpretation involves all three simultaneously: a logical dependency carries proportional weight and must be integrated over a temporal dimension.

The three sovereignties each read the nine temporal dimensions and assign a valence of negative, neutral, or positive to each. When all three sovereigns agree, the result is a pure state:

• All positive: conception, reciprocity, lucidity, dream, affection, virtue
• All neutral: resolution, laterality, wisdom, fiction, understanding, constancy
• All negative: execution, unilaterality, delusion, nightmare, indifference, vice

When the sovereigns diverge, the result is a state of tension. On the past dimension: theocratic negative, democratic positive, autocratic positive produces corruption. Theocratic positive, democratic negative, autocratic negative produces perfectionism. In total: 27 states across 9 dimensions gives 243 named interpretation states, each carrying a moral, affective, or epistemic label.

Map your reasoning system as a cycle, not a pipeline. Identify which nodes absorb imperfection as buffers and which transform it as processors. A processing node with no buffer downstream will spill imperfection into adjacent modules.

Figure: 9 — Nodes in the cyclic intelligence model: three equivalent buffer spaces and six processing modules (Wiener, Cybernetics: Control and Communication in the Animal and the Machine, MIT Press, 1948)

Myth: Intelligence is a pipeline from input to output
Reality: A pipeline cannot learn from its own outputs. Any system that updates its interpretation based on the history of what it has emitted requires a cycle, not a pipeline. (Wiener, Cybernetics: Control and Communication in the Animal and the Machine, MIT Press, 1948)

Input imperfections (what corrupts information as it arrives):

• Uncertainty: the input is incomplete; which branch is true is unknown. Formal equivalent: entropy H.
• Conflicts: contradictory signals pull in incompatible directions; too much information with opposing magnitudes. Equivalent: KL divergence.
• Noise: the signal is present but buried in irrelevant variation; generalisation is hard. Equivalent: signal-to-noise ratio.

Output imperfections (what corrupts information as it is emitted):

• Disorder: the output lacks structure; elements are not organised into coherent relations. Equivalent: high Kolmogorov complexity.
• Constraints: the output is over-constrained; competing requirements limit what can be expressed. Equivalent: Lagrange multipliers.
• Redundancy: the output repeats itself; over-specified and poorly encoded. Equivalent: 1 - H/Hmax.

These six cannot be eliminated. They can only be redistributed around the cycle. Institutional policy is precisely the mechanism by which this redistribution is determined:

1. Radical policy (overfitting): suppresses noise and uncertainty by force, generating disorder and constraints downstream.
2. Primitive policy (underfitting): ignores imperfections, which accumulate until the system collapses.
3. Moderate policy (fitting): accepts a stable, bounded level of each imperfection: the constitutional equilibrium.

The institutionalisation consequences follow from which policy governs a domain:

• A radical policy produces totalitarianism: coercive over-constraint propagates into adjacent domains.
• A moderate policy produces constitutionalism: imperfections are acknowledged, distributed, and bounded.
• A primitive policy produces anarchism: unmanaged imperfections accumulate and cascade outward.

Map each stage of your reasoning pipeline to one of the six imperfections: uncertainty, conflicts, noise, disorder, constraints, redundancy. Reducing one without tracking where it goes means it reappears downstream under a different name.

Figure: 6 — Forms of information imperfection: three corrupting input flows, three corrupting output flows (Shannon, A Mathematical Theory of Communication, Bell System Technical Journal, 1948)

Myth: Better algorithms eliminate information imperfections
Reality: No algorithm removes imperfection from a cycle. It redistributes it. Suppressing noise upstream generates disorder or constraints downstream. The total burden is conserved. (Shannon, A Mathematical Theory of Communication, Bell System Technical Journal, 1948)

1. Theocratic: a single external authority designates the correct interpretation. The agent defers unconditionally. Reality is the sovereign; experiments are how you consult it.
2. Democratic: the agent and its environment jointly produce interpretation through interaction. Meaning is negotiated in real time. Spoken language works this way.
3. Autocratic: the agent alone decides what its observations mean. Useful for speed, dangerous for accuracy: it is the failure mode of pure self-reference.

Any system capable of reasoning across domains uses all three simultaneously. The design question is which sovereign governs which class of observation, and whether the system tracks this explicitly.

When a system does not track it, the modes bleed into each other. A cached self-referential interpretation gets treated as externally validated. A negotiated meaning gets treated as a universal law. The errors are invisible until they are catastrophic.

Time compounds this. Every interpretation also exists in time, and time has structure:

• The changing: past, present, future (what transforms as time passes)
• The enduring: eternal, ephemeral, instantaneous (what persists or disappears)
• The oscillating: punctual, trending, repetitive (what pulses, drifts, or recurs)

Nine temporal dimensions. An interpretation made yesterday under an ephemeral authority that has since dissolved is a different object from an interpretation made now under an eternal law. Conflating them is how reasoning systems produce confidently wrong answers that are undetectable from the inside.

For any class of observation your system makes, decide in advance which sovereign mode governs it: external authority, mutual negotiation, or self-reference. Systems that mix modes silently produce contradictions that more data cannot fix.

Figure: 3 — Modes of interpretive sovereignty: theocratic (external authority), democratic (negotiated), autocratic (self-referential) (Wittgenstein, Philosophical Investigations, Blackwell, 1953)

Myth: An intelligent system needs a single consistent interpretation mode to avoid contradiction
Reality: Every real system uses all three modes simultaneously in different domains. The problem is not mixing them. The problem is mixing them without knowing which mode governs which observation. (Wittgenstein, Philosophical Investigations, Blackwell, 1953)

The standard framing is: symbols are meaningless without connection to the world, and the way you connect them is through sensory data. Feed the system enough images, enough audio, enough text paired with observation, and the symbols will acquire grounded meaning. This is the implicit assumption behind most current deep learning work.

I think this framing is wrong in a specific and important way.

More data tells you how symbols co-occur. It tells you that 'apple' appears near 'red', 'round', 'fruit'. It does not tell you what an observation is. When a sensor returns a reading, the question of what that reading means is not settled by more readings. It is settled by someone deciding.

The architecture I am working on treats grounding as a governance problem:

• who has the authority to classify an observation
• how disputes about classification are resolved
• what happens when two observers disagree about what they are looking at
• how new observational categories get introduced and ratified

This is not a machine learning question. It is a political and institutional question. Every stable grounding system in human history (scientific taxonomy, legal definitions, medical diagnosis) is held together not by data but by an institution with the authority to say 'this is what this means.'

The interesting thing about AGI is that we are trying to build a system that operates across domains, which means it has to navigate many different grounding authorities at once. Science says one thing. Law says another. Common usage says a third. The system has to know not just what the symbol means but whose definition applies in this context.

Treating grounding as a data problem misses this entirely. You can train on all the scientific literature and still not know that in a legal context, the word 'intent' means something different from what it means in a psychology context. The data is the same. The authority is different.

I do not have a full solution. What I have is a design principle: every observation in the system should carry a tag for the institution or process that defined it, and reasoning across observational domains should be explicit about when it is crossing grounding boundaries.

When designing any system that interprets observations, write down explicitly who has the authority to define what each observation means. If you cannot name a person or institution, the grounding is implicit and will break under disagreement.

Figure: 1980 — Year Harnad first formalized the symbol grounding problem, asking how symbols acquire meaning rather than just relational structure (Harnad, The Symbol Grounding Problem, Physica D, 1990)

Myth: Grounding is a data problem: give the model enough sensory data and symbols will acquire meaning automatically
Reality: More data tells you what symbols co-occur. It does not tell you who has the right to define what an observation means. That is a governance question, and no dataset answers it. (Harnad, The Symbol Grounding Problem, Physica D, 1990)

42 is a tuition-free software engineering school in Paris founded by Xavier Niel. There are no teachers, no classes, no diplomas in the conventional sense. You learn by doing projects, graded by other students. To get in, you have to survive the Piscine.

The Piscine is a month-long selection competition. You move in, work on C programming exercises from morning to midnight, get evaluated daily by peers, and at the end the school picks who continues. It is not a test of prior knowledge. It is a test of how fast you learn under pressure with very little guidance.

I spent the month not knowing if I was doing well. There are no grades during the Piscine, no ranking, no feedback from the school. You submit your work, other students evaluate it, and you wait. The selection criteria are not published. You have no idea where you stand.

That uncertainty was the most useful part. I had to keep working without external validation, which is the condition under which most real work happens anyway.

What the month forced me to do:

• Read documentation instead of waiting for explanations
• Ask peers for code review instead of expecting a teacher to catch my mistakes
• Keep submitting even when I was not sure the solution was right
• Rebuild completely when a peer evaluation showed I had misunderstood the problem

Evaluation had two layers. Peers reviewed your code directly. But there was also the moulinette: an automated system that compiled and ran your code against test cases without telling you what the tests were. You submitted, it returned pass or fail, nothing more. You had to infer what you had missed from the output alone. That second layer was harder to game and harder to ignore.

There was a third system called Megatron. At some point during the Piscine you had to name which candidates you recommended for admission. The school used those nominations to rank candidates, probably something close to PageRank: being recommended by someone who is themselves highly recommended counts for more. You could not know your own score. You could only decide who you genuinely thought deserved a place.

I learned more C in that month than I had in any formal course. Not because the material was better, but because the stakes were real and the feedback was immediate. Every day you either passed the exercise or you did not. That is a different kind of learning than reading about something you might one day be tested on.

The acceptance email arrived this morning at 12:46 AM. I start in September.

I also made many friends. A month of working side by side until midnight, evaluating each other's code, and competing for the same spots turns strangers into people you actually know.

If you want to test your real level in a new discipline, find a selection process that does not care about your credentials and put yourself through it.

Figure: 1 month — Duration of the 42 Piscine selection process, with no grades or ranking published during it (42 Paris, 2016)

Myth: You need teachers to run a school
Reality: 42 Paris has no teachers. Students learn by doing projects evaluated by other students and an automated system. The school runs, and people learn. (42 Paris pedagogy, 2016)

Not because I plan to publish the translation. Because translation is the most aggressive reading technique I know.

Here is the problem with reading a technical book: comprehension is easy to fake. You read the sentence, your eyes move, and your brain produces the sensation of understanding. You can read twenty pages of a machine learning textbook and retain nothing, because passivity produces the illusion of fluency without the encoding.

Translation breaks that illusion in the first paragraph.

You cannot translate a sentence you do not understand. The moment you try, you discover immediately whether you grasped it or merely passed your eyes over it. Every ambiguous pronoun, every technical term used without definition, every causal chain you assumed rather than followed: all of it surfaces the moment you try to render the sentence in another language.

This is active recall in its most demanding form. Not re-reading, not highlighting, not taking notes in the margin. Production. You are generating the content from your own encoding rather than recognising it from the page.

The cognitive load is exactly the right kind. You are not struggling with an unfamiliar language on top of unfamiliar content. You are using your strongest language as a forcing function to test your encoding of new ideas. When the French sentence does not come, the problem is not my French. It is that I did not understand the original.

Some practical observations after several chapters of Heaton:

• You cannot skim. Every shortcut you would normally take on a difficult paragraph is blocked. This is a feature.
• Analogies reveal themselves. Heaton uses analogies to explain neural network concepts. Translating them forces you to decide whether the analogy holds or just sounds plausible.
• You build a personal vocabulary. When you decide how to render a term, you own the definition. You made the decision. The word is yours.
• Errors are obvious. If your translation is awkward, you go back to the original. That second visit is where the learning happens.

The method scales to any subject and any language pair, including translating dense academic prose into plain speech in your own language. That version is slower than ordinary reading and faster than forgetting everything by Thursday.

Pick one technical book chapter you want to master and translate it into your native language or simpler prose before moving to the next one. You will catch every sentence you do not actually understand.

Figure: 50% — Better long-term retention from active recall versus passive re-reading (Karpicke & Roediger, Science, 2008)

Myth: Reading a technical book twice is the best way to absorb it
Reality: Passive re-reading produces the illusion of fluency. Translation forces production: you cannot render a sentence you do not understand. (Karpicke & Roediger, Science, 2008)

None of them came from a cold email or a job board. Every single one came through a recommendation. Someone knew me, trusted my work, and told someone else who needed help. That was the entire sales process.

The work itself is focused: I take old websites that were built before smartphones mattered and convert them to mobile responsive. Most small business sites from 2008 to 2012 were built for desktop only. They look broken on a phone. The owners know it. They just do not know how to fix it or who to trust.

A recommendation solves the trust problem immediately. I do not have to convince anyone I am competent. Someone they already trust has already done that.

I should be honest: when I took the first project I did not fully know how to do it. I had a vague idea. I knew roughly what responsive design meant and had seen enough examples to believe I could figure it out. I did not let that stop me. I learned what I needed as I went, project by project. The gaps closed faster than I expected because the work was real and the deadline was real.

What I have learned so far:

• The referral conversation happens faster than any sales call I could have made
• Clients who come through recommendations already have realistic expectations
• Doing good work on one project is the most reliable source of the next project
• Mobile responsiveness is a concrete, visible problem: it is easy to explain why it matters and easy to show when it is fixed
• I ask to be paid upfront. Freelancers routinely get stiffed after delivery. Payment before work starts eliminates that problem entirely.

I do not know yet how far recommendations will scale. But for now the pipeline is real and the work is straightforward.

If you want freelance clients, tell people you trust what you are doing and what kind of work you are looking for. Recommendations beat cold outreach every time.

Figure: 100% — Share of my first freelance clients acquired through personal recommendations, not cold outreach (Personal records, 2015)

Myth: You need a portfolio site and cold outreach to get your first freelance clients
Reality: Every one of my first clients came through someone who already knew me. A warm recommendation from a trusted contact converts faster than any portfolio. (Personal experience, 2015)

Ian Goodfellow and his co-authors at Montreal describe a system where two neural networks compete: one generates images, the other tries to identify which images are fake. The generator gets better at fooling the discriminator. The discriminator gets better at catching it. After enough rounds, the generator produces images that look real but are not. Nobody took them. Nobody drew them. The network made them.

I am studying art direction at Penninghen. The program is rigorous and the craft education is real. But reading this paper made me feel like I was learning to sharpen a pencil the week the printing press arrived.

That is probably too dramatic. But the feeling is genuine and I have learned to take that kind of feeling seriously.

What the GAN paper changed in how I think:

• Visual output is no longer the bottleneck. A trained network can generate thousands of images faster than I can evaluate them.
• The interesting design problem is no longer making the image. It is specifying what you want, curating what you get, and knowing when you have it.
• The craft of art direction is shifting from production to judgment. That is actually a more interesting problem.
• Generative design is not about replacing designers. It is about what design looks like when generation is cheap.
• The gap between someone who understands these systems and someone who does not will matter more over time, not less.

I am going to stop my studies at Penninghen and reorient toward generative design and the intersection of neural networks and visual output. I do not know exactly what that means yet in terms of what I build or where I end up. But I know I would rather be confused about the right problem than confident about the wrong one.

If a paper or idea makes you feel like your current direction is solving the wrong problem, treat that feeling seriously. Switching costs are real but staying on the wrong path has costs too.

Figure: ∞ — The generator's output space: given a random noise vector, it can produce an image that has never existed before (Goodfellow et al., Generative Adversarial Networks, NeurIPS 2014)

Myth: Design is a human craft that algorithms can assist but never replace
Reality: The GAN paper showed a network generating images that do not correspond to any real object. The output is not assistance. It is authorship. The boundary between tool and creator moved in 2014. (Goodfellow et al., Generative Adversarial Networks, NeurIPS 2014)

Thomas had been working at Google before we decided to team up. We met at an event for entrepreneurs. That background shaped how he approached the data pipeline: methodical, well-instrumented, and with a clear sense of what mattered at scale.

The idea is simple: your phone already contains a record of every relationship you have maintained. Not the content of the messages. The metadata. Who texts whom first. How often. Whether the ratio is equal or lopsided over time.

Love Score reads that metadata and plots every contact as a point on a two-axis chart.

The two axes:

• Balance: the ratio of messages sent to messages received. A contact in the center is an equal exchange. A contact far to one side means one person is doing most of the initiating.
• Passion: the total volume and recency of the exchange. A contact high on this axis has an active, frequent thread. A contact at the bottom is someone you have drifted from.

When you see your contacts plotted together, patterns appear immediately. You can see who you are investing in asymmetrically, who has gone quiet, who the relationship has stayed consistent with for years.

What I learned building this:

• The most revealing data is usually the data you already have. You do not need to instrument new behavior to understand old patterns.
• Two axes is the right number for a first look. More than two and people lose the thread. Fewer and you lose the nuance.
• People are curious but also nervous to see their relationships quantified. The visualization surfaces things they already felt but had not articulated.
• Android at this point was fragmented enough that SMS data access worked differently across manufacturers. A lot of the build time was normalization.
• Thomas and I divided the work well. He handled the data pipeline and I handled the visualization and product decisions.

I did most of the user testing. The pattern was consistent: people were curious about the chart until they saw their own data. Then something shifted. Seeing your contacts mapped by how balanced and active each relationship is turns out to be more confronting than interesting. People did not want to sit with what it showed them. Most sessions ended with the person closing the app rather than exploring further.

We also could not figure out a business model that did not compromise the thing that made the app trustworthy. Charging for the app was the only clean option. Anything involving data (even anonymized aggregate insights) felt like it broke the promise of the product, which was that nothing left your device. The app's integrity and any revenue model based on data were mutually exclusive.

I do not know how many people will use it or whether it will matter. But building it clarified something: the gap between the data you already have and the insight you could extract from it is almost always larger than you think.

To understand a relationship pattern, measure the metadata not the content. Frequency and direction of contact reveal dynamics that no single message can.

Figure: 2 — Axes used to map every contact: balance (who initiates more) and passion (how active the exchange is over time) (Love Score, Android app, July 2014)

Myth: You need to read the messages to understand a relationship
Reality: SMS metadata alone (who sends first, how often, how the ratio shifts over time) tells you the structure of a relationship without reading a single word. (Love Score, Android app, July 2014)

The space is small and clean. There are explanations on the walls and a few terminals. The people there were enthusiasts, early adopters, and a handful of journalists. Nobody looked like a banker.

I bought a small amount of bitcoin before I left. I am not sure why exactly. I did not have a plan for it. I did not have a thesis about where the price was going. I just felt like I should have some, the same way you feel like you should read a book you keep hearing about even before you know if it is good.

What I actually understood at that point:

• Bitcoin is a currency not controlled by any government or central bank
• Transactions are recorded on a public ledger nobody owns
• The supply is capped and new coins are created by solving computational puzzles
• A lot of very technical people take it seriously
• A lot of other people think it is a scam

What I did not understand:

• What to do with it after buying it
• How wallets actually work or how to keep it safe
• Why the price moved the way it did
• Whether any of this would matter in ten years

The honest answer is that I bought it because being in the room made it real in a way that reading articles had not. The transaction happened. I had a small number in a wallet on my phone.

I do not know if this will turn out to have been a smart decision or an irrelevant one. But I know that having a small amount of something focuses your attention differently than having none of it. I will follow this more carefully now.

When something new confuses you but still pulls your attention, buy or build the smallest possible version of it. The confusion is a signal worth paying attention to, not a reason to wait.

Figure: ~330 EUR — Approximate price of one bitcoin in euros on the day La Maison du Bitcoin opened in Paris, May 13, 2014 (Bitcoin price data, CoinMarketCap; EUR/USD rate, May 2014)

Myth: Bitcoin is used by criminals and will be shut down by governments
Reality: That was the mainstream view in 2014. The same year, France opened a legal bitcoin shop in central Paris. The technology survived every shutdown prediction and every obituary written about it. (La Maison du Bitcoin inauguration, Paris, May 2014)

The range was the thing. I expected plastic prototypes and novelty objects. What I found was a floor split between things that already exist in production and things that are about to.

What was on the floor:

• Titanium brackets printed for aerospace applications, already certified for use in aircraft
• Bone graft scaffolds printed from biocompatible materials for reconstructive surgery
• Food printed in chocolate and sugar, shaped to order in real time
• Running shoes with soles printed to the geometry of a specific person's foot
• Architectural models printed overnight that would have taken a model shop a week
• A full dress printed in nylon, worn by the person who designed it

None of it felt like a demo. The aerospace parts are in planes. The medical scaffolds are in patients. The food printer had a queue.

The part that stuck with me is how much the manufacturing assumption changes. Right now the cost of making one thing and the cost of making ten thousand things are completely different. Tooling, molds, minimum order quantities: all of that assumes you are making the same thing many times. Printing breaks that assumption. The cost of making one and the cost of making ten is almost the same. What that does to small-batch production, custom medical devices, local manufacturing is not fully worked out yet.

I do not know which of these applications will be mainstream in ten years and which will stay niche. But I know that walking through that show felt the same way I imagine it would have felt to walk through an early computer exhibition in 1975. The technology is not finished. The use cases are not obvious yet. But the direction is clear.

Pick one physical object you use every day and look up whether someone has printed a version of it. The gap between what exists and what is possible in your field is where the opportunity is.

Figure: 2013 — Year the 3D Printshow brought industrial, medical, and consumer 3D printing under one roof at the Carousel du Louvre, Paris (3D Printshow, Paris, November 2013)

Myth: 3D printing is a toy for hobbyists making plastic figurines
Reality: At the 3D Printshow in Paris I saw printed titanium aircraft brackets, printed bone grafts for surgery, and printed food. The same technology runs from a desktop machine to a factory floor. (3D Printshow, Carousel du Louvre, Paris, November 2013)

The school is on Rue du Dragon in the 6th arrondissement. It trains art directors and graphic designers. The program is five years.

I applied because I wanted to understand visual communication at a level that goes beyond taste. I can tell when something looks good. I cannot always explain why, and I cannot always reproduce it deliberately. That gap is what I want to close.

What the first day looked like:

• A studio environment, not a classroom. Tables, not chairs in rows.
• Work already on the walls from previous years. The standard is visible immediately.
• Faculty who work professionally. They are not academics explaining design from a distance.
• A small cohort. Tables, not chairs in rows.
• Critique built into the structure from day one. You show work. People tell you what is wrong with it.

I do not know yet how long I will stay or what I will build from here. What I know is that I have been interested in how things look and why some things communicate clearly and others do not. I want to understand that seriously, not as a hobby.

The school treats it seriously. That is why I am here.

If you want to get serious about a craft, find the institution that treats it most rigorously and put yourself in that room. Proximity to people who are better than you is the fastest feedback loop.

Figure: 1954 — Year Penninghen was founded in Paris, one of the oldest and most selective schools for art direction and graphic design in France (Esag Penninghen, Paris)

Myth: Design is something you learn by doing, not by going to school
Reality: Doing without feedback produces confident mediocrity. A rigorous school compresses years of self-taught trial and error into a structured critique environment. Both matter, but school accelerates the early part. (Personal experience, 2013)

The thing that changed my approach was interactivity. Every mockup tool I had used before produced a static image. You could look at it but not touch it. Fluidui lets you link screens together so that pressing a button actually navigates to the next screen. You click through the design the same way a real user would.

That gap between looking at a design and clicking through it turns out to be enormous. The moment I made my first tap target too small and had to reach for it with my thumb on a phone preview, I understood responsive design differently than I had from reading about it.

What I learned from the first week:

• Static mockups lie. You think you understand the layout until you try to tap the button you drew.
• Showing someone a clickable prototype gets a real reaction. Showing a screenshot gets a polite one.
• The fastest way to know if an idea works is to make it clickable and hand it to someone.
• You find the broken transitions first. Navigation problems are invisible on paper.
• Free tools have feature limits that force good decisions. Constraints on screen count made me cut.

I do not know yet if I want to become a UI designer professionally. But I know that building mockups and clicking through them has taught me more about how interfaces work than anything else I have tried. The tool is free. The feedback is immediate. There is no reason to wait.

Pick one screen from a product you use every day and rebuild it as a clickable prototype in a free tool. The gap between what you intended and what you built is the lesson.

Figure: 2012 — Year browser-based interactive prototyping tools became accessible to non-engineers, letting anyone design clickable UI mockups without writing code (Fluidui.com, 2012)

Myth: You need to learn to code before you can design real user interfaces
Reality: Interactive prototyping tools like Fluidui let you build clickable mockups in the browser with no code. Clicking through your own design teaches you more about UX than reading about it. (Personal experience, 2012)