DEV Community: VelocityAI

The Post-Literate Child: What Happens When Kids Learn to Speak Before They Learn to Read—But to AI?

VelocityAI — Fri, 23 Oct 2026 15:58:44 +0000

A five-year-old in my extended family has been having full conversations with a voice assistant for two years. She has never typed a prompt. She has never read a response. She speaks, the machine speaks back, and the loop closes without a single written word passing between them. Last month she asked it to tell her a story about a rabbit who was afraid of the dark, then interrupted mid-story to correct it: “No, the rabbit isn’t scared of the dark, she’s scared of being alone.” She was not reading. She was not writing. She was doing something no generation has done before: conducting a sustained intellectual relationship entirely through speech, with a system that answers back.

That’s the leading edge of a shift that the AI industry has barely begun to think about, and that parents and educators are already living through. For the first time in centuries, a child can acquire knowledge, conduct inquiry, and produce creative work without ever passing through the written word. The written word is no longer the bottleneck.

Here’s the claim I want to test: voice-first AI is not just a new interface. It’s a new cognitive environment, and it may break the assumption that literacy is the foundational skill of an educated mind. That assumption has been load-bearing for every education system in the world. If it’s wrong, the consequences are enormous, and they’re coming faster than the institutions that will have to respond to them.

The Sacred Cow: “Literacy Is the Foundation of Thought”

This is the belief I want to dismantle, and it’s the most deeply held assumption in education.

The claim goes like this: reading and writing are not just communication skills. They are the substrate of complex thought. You cannot think clearly without writing. You cannot reason at length without reading. Literacy is the gateway to everything else, and every child must pass through it.

This belief has been reasonable for roughly 5,000 years. It is now, for the first time, questionable.

Here’s why. The reason writing was the substrate of thought is that it was the only reliable external memory system. You could not hold a complex argument in working memory. You could not iterate on a draft without a draft. You could not accumulate knowledge across a lifetime without a written record. Writing was the technology that made sustained reasoning possible.

Voice-first AI changes the substrate. A child can now hold a complex argument in conversation with a system that remembers the argument, can be asked to restate it, can be asked to check it for consistency, and can be asked to extend it. The external memory function that writing used to serve is now served by the conversation itself. This is not a trivial substitution. It’s a different cognitive technology with different affordances.

What writing does that voice-AI does not:

Slows thought down. Writing forces you to commit to a specific sequence of words. This is uncomfortable and productive. It’s where a lot of clear thinking happens.Leaves a permanent, revisable record. A written draft can be edited line by line. A spoken conversation, even with a transcript, is different in kind.Forces you to externalize structure. Paragraphs, headings, and punctuation are a technology for organizing thought that voice rarely demands.

What voice-AI does that writing does not:

Matches the speed of thought. Speech is roughly 150 words per minute. Typing is roughly 40. The gap matters for brainstorming, for dialogue, and for iterative refinement.Allows for immediate clarification. You can interrupt, correct, and re-ask without any friction. This is closer to human conversation than any written medium.Removes the mechanical barrier. A child who cannot spell can still compose a story. A child who cannot type can still organize an argument. The mechanical gate is gone.

The honest version: writing and voice-AI are different cognitive technologies, each with strengths the other lacks. The claim that writing is the foundation is not wrong because writing is bad. It’s wrong because it’s now one option among several, and the children growing up with both will develop hybrid cognitive skills that neither pure-writing nor pure-voice cultures possess.

Why This Is Not Just “Kids These Days”

I want to be careful here, because this is exactly the kind of topic where every generation’s “kids these days” panic gets dusted off and repackaged. I’m not making that argument. The kids are not getting worse. They’re getting different, and the difference is being underestimated by almost everyone.

Here’s what’s actually new, and why it’s not just a change in medium:

The feedback loop is now conversational.

Every previous educational technology (books, radio, TV, computers) was one-directional. You consumed, you did not converse. Voice-AI is the first educational technology that talks back, remembers, and adapts. A child can now have a sustained Socratic dialogue with a system that will follow their line of reasoning, push back, and ask the next question. This is closer to tutoring than to any previous medium, and tutoring is the most effective educational intervention ever measured.

The system can meet the child where they are.

A child who speaks in fragments, makes grammatical errors, and jumps between topics can still be understood by a modern voice model. The system does the work of interpreting and responding to intent. This removes the failure mode that historically blocked young children from using text-based systems: the mechanical and linguistic gate. A five-year-old can now have a conversation about the causes of rain that is at their level of understanding, in their language, at their pace.

The child can produce before they can spell.

A child who cannot write can now dictate a story, hear it read back, ask for revisions, and iterate. The barrier to authorship has fallen to near zero for a population that has never had access to authorship before. This is a bigger deal than it sounds. Most children’s first experience with writing is drudgery: handwriting practice, spelling tests, grammar drills. Voice-AI lets them experience composition first, mechanics later. The order matters.

The child can be evaluated in conversation.

Voice models can assess comprehension, reasoning, and vocabulary in real time, through dialogue, without a written test. This is a fundamentally different assessment paradigm, and it’s more humane. It’s also more accurate for young children, whose written expression lags their understanding by years.

None of this is speculative. These capabilities are shipping today. What’s missing is a coherent theory of what they do to a developing mind.

What We Actually Don’t Know

I want to be honest about the epistemic state here, because the discourse around this topic is mostly speculation dressed as certainty.

We know almost nothing about what happens to a child’s cognitive development when voice-AI is a primary mode of inquiry. The empirical literature is essentially empty. The adjacent literature (TV, screens, early reading) is not directly applicable because it involves passive or one-directional media, not conversational systems.

Here’s what we’d need to know to have a real conversation:

Does voice-first interaction delay or accelerate reading acquisition? There’s a plausible case for each. Voice removes the pressure to read. It also builds vocabulary and narrative structure that support later reading.Does conversational AI improve or degrade sustained attention? The system is always responsive. It never demands that the child wait. It may train a child to expect responsiveness, which could make slow media (books, lectures) harder to tolerate.Does conversational AI improve or degrade memory consolidation? Passive consumption doesn’t consolidate. Conversation might, if the child does the retrieval. The open question is whether voice conversation produces the same retrieval effort as writing.Does the absence of writing practice affect the development of structured reasoning? Writing forces structure. Speaking in conversation does not. The child may develop fluent speech and weak structure, or may develop structure through the system’s scaffolding.

We don’t have answers to any of these. We have intuitions, and the intuitions are mostly driven by ideology. The honest position is: this is a large-scale natural experiment, and we are running it on a cohort of children with almost no measurement infrastructure.

That’s the thing that should worry you, more than any specific effect. It’s the absence of measurement.

The Evidence From Adjacent Domains

I said the direct evidence is thin. Let me be more specific about what we do know from adjacent domains, because it’s more informative than the pure speculation.

Bilingualism research shows that children who acquire language through multiple modalities develop more flexible cognitive control, not less. This is a small point in favor of voice-plus-reading over either alone.Oral cultures have produced sophisticated philosophy, law, and history without widespread literacy. The claim that literacy is the substrate of complex thought is a claim about the affordances of writing, not a claim about the necessity of writing. Oral cultures had other technologies: mnemonic devices, formulaic repetition, community memory. Voice-AI is a new technology in that lineage.Conversational tutoring (Bloom’s 2-sigma problem) has repeatedly shown massive learning gains for one-to-one tutoring over classroom instruction. If voice-AI can approximate a tutor, the effect on learning could be significant.Dictation research shows that children who dictate stories produce more sophisticated narratives than children who write them, because the mechanical burden of writing is removed and working memory is freed. This is one of the clearest pieces of evidence that the mechanical gate is a real constraint on composition.

The pattern: voice and conversation are not inferior to writing on every dimension. They’re inferior on some (permanence, structure, revision) and superior on others (fluency, speed, comprehension, access). The child who grows up with both is not a deficient reader. They’re a different kind of thinker, and we don’t have a name for that kind yet.

What To Actually Build

If you’re building voice-first AI for children, here are the three highest-leverage moves, and they’re not what most teams are doing.

Build for retrieval, not just response.

The biggest cognitive risk of conversational AI is passive reception. The system answers, the child nods, the knowledge does not consolidate. The fix is to make the system ask the child to retrieve. Not “do you understand?” but “can you explain that back to me in your own words?” and then “what’s the part you’re least sure about?” This is a design choice, not a model choice, and it’s the difference between a tool that teaches and a tool that entertains.

A rough sketch of the interaction pattern:def tutor_turn(child_input, topic, history):
response = generate(child_input, topic, history)

Force retrieval before advancing

if not history.recently_retrieved(topic):
return response + ask_retrieval(topic)

Force self-assessment

if not history.recently_self_assessed(topic):
return response + ask_uncertainty(topic)

Advance only after retrieval

return response

The specific implementation doesn’t matter. The principle does: the system should treat conversation as a vehicle for retrieval, not just for delivery.

Make writing visible, always.

The worst possible outcome is a cohort that can speak fluently about complex topics but cannot write about them. The fix is not to force writing. It’s to make writing continuously visible. Every spoken response should produce a written artifact: a transcript, a summary, a highlighted key sentence. The child sees that their speech becomes text, and that text is editable. The goal is to make writing feel like a natural extension of speaking, not a separate skill.

Design for the transition, not the endpoint.

Voice-first AI is not the destination. It’s the on-ramp. The design question is not “how do we make voice-first interaction as good as possible?” It’s “how do we make voice-first interaction a bridge to writing, reading, and structured reasoning?” The child who speaks to the machine should, within a year, be reading the transcripts, editing them, and asking to write things themselves. The system should nudge them toward writing without ever making writing feel like a punishment.

The Mental Model

Here’s the lens I want you to keep.

Literacy is not a foundation. It’s a technology. It has been the dominant cognitive technology for a few thousand years, but it’s not the only one, and it’s not the necessary one. The children growing up with voice-AI will develop cognitive skills that are neither “literate” nor “illiterate” in the old sense. They’ll be something else, and the something else is largely undefined.

The right question is not “will voice-AI make children worse at reading and writing?” It’s “what new cognitive skills will children develop, and how do we measure them, and how do we make sure the old skills aren’t lost in the process?” The answer to that question is not predetermined. It’s being decided right now, by the design choices of a small number of teams building voice-first products for children.

If you’re on one of those teams, you are not building a toy. You are building a cognitive environment for a generation. The design choices you make in the next two years will shape how children think for the next fifty. That’s not hype. That’s just the size of the thing.

What’s your read? If you’ve watched children interact with voice AI, what changes have you noticed? And if you’re building in this space, what’s the hardest design tradeoff you’ve run into? Drop it in the comments. I’m genuinely curious whether the oral-culture analogy holds up in practice.

The Grandparent Prompt: What Happens When Elderly Users Become the Most Proficient Prompters?

VelocityAI — Thu, 22 Oct 2026 14:42:38 +0000

My mother is 71. She has been using ChatGPT for eight months. Last week she sent me a prompt she'd written to help her plan a four-day trip to Portugal, and it was better than anything I've written in two years. It had a role assignment, a constraints section, a tone specifier, a multi-step reasoning instruction, and a self-check clause. She didn't know the terms for any of that. She just knew what she wanted, and she'd iterated until she got it.
I'd been operating on the assumption that she was the exception. She's not. She's the leading edge of a pattern that the AI industry has been almost completely blind to: the heaviest, most patient, and increasingly most proficient users of language models are not the young. They're the retired.
This piece is about why that's happening, why it matters, and one sacred cow that the AI industry needs to stop grazing on before it builds another generation of products for the wrong demographic.
The Sacred Cow: "AI Proficiency Belongs to the Young"
Here's the belief I want to dismantle, and it's practically an axiom in every demographic survey and product brief in the industry.
The claim goes like this: younger people are digital natives, so they'll adopt and master AI faster. Older people will lag, need training, and use it in shallow ways.
This is measurably wrong on the dimension that matters.
What surveys actually show:
Young people are more likely to try AI tools. They adopt more quickly, sample more products, and are more willing to experiment.
Young people are less likely to persist with a single tool over time. Their usage is broad, shallow, and fragmented across many apps and use cases.
Older users who adopt AI spend dramatically more time per session. Not slightly more. Multiple times more. They read the outputs. They revise the prompts. They run variations. They treat it like a craft.
The result is a quiet inversion. The cohort with the most breadth of AI use is young. The cohort with the most depth of AI use is elderly. And depth, in language models, is where proficiency lives.
If you want to find the best prompters in the world right now, don't look at the 22-year-old prompt engineers on Twitter. Look at the 68-year-old retired nurse who's been using Claude to help her write a memoir for nine months and has developed a personal prompt library she refines every week.
Why the Elderly Are Actually Better at This (Not Just More Patient)
Let me be specific, because "they have more time" is the lazy explanation and it's not the whole story.

They have more to ask about. A retired person has 40 to 60 years of lived experience across multiple domains: career, family, health, finances, relationships, loss, travel, craft. The models are most useful on tasks that require domain knowledge to formulate well. A 25-year-old asking an AI for career advice has thin priors. A 65-year-old asking for career advice has decades of context, and the model's output is far more useful because the input is richer.
They've had practice with the pre-AI equivalent. The best prompters are not the ones who learned prompt engineering from a course. They're the ones who spent 40 years writing letters, crafting memos, negotiating with contractors, writing eulogies, drafting medical questions, and asking precise questions of doctors, lawyers, and bureaucrats. The underlying skill is the same: formulating a clear request and evaluating the response. Younger users have had less practice because they've had less to practice on.
They're patient with iteration. The single biggest determinant of prompt quality is iteration count. A prompt that works is usually the fifth or tenth version. Young users tend to try once or twice, get a mediocre answer, and switch tools. Older users tend to iterate because they've learned from a lifetime of tasks that mastery requires repetition. They are not in a hurry. This is the decisive advantage.
They're better at evaluating outputs. Younger users grew up with outputs that were either right or wrong, and they're calibrated to fast feedback. Older users grew up with outputs that were often ambiguous, requiring judgment. When the model produces something that sounds plausible but is subtly wrong, older users are more likely to catch it, because they've spent decades catching subtle wrongness in human communication.
They're not trying to look cool. This one is underrated. Young users have a social incentive to look like they know what they're doing. Older users don't. They ask dumb questions, they push the model to explain things twice, they ignore features they don't need. The result is that they actually learn the tool, while younger users perform fluency without building it. Put together, these advantages are structural, not incidental. They don't depend on the tool getting better. They depend on the user having a lifetime of practice that the tool rewards. The Evidence (Such as It Is) I want to be honest about the limits here. The empirical literature on AI proficiency by age is thin and mostly measures usage frequency, not proficiency. The studies that exist tend to show: Older users (65+) adopt more slowly but use more intensively when they adopt.

Older users report higher satisfaction with AI outputs on writing and research tasks, and lower satisfaction on tasks requiring fast visual processing (which is a UI problem, not a model problem).

Older users are more likely to use voice input, which produces longer and more natural prompts than typed input.

In one internal study at a major AI company that I've seen, users over 60 had the highest rate of "prompt refinement" per session of any age cohort.

The pattern is consistent, but the sample sizes are small and the selection effects are real. The elderly users who adopt AI are not a random sample of the elderly. They're the ones with the time, curiosity, and resources to try. That's a real limitation.
But the limitation cuts the other way too. The young users who are celebrated as "AI natives" are also not a random sample. They're the ones who happen to be on Twitter and TikTok, which is a different and equally biased sample. Both cohorts are selected. The question is which selection is more predictive of long-term proficiency, and I'd argue it's the one that includes patience and iteration.
What This Means for Product Builders
If the elderly are the deepest users, the industry is building for the wrong demographic, and it's leaving money and product quality on the table.
Concrete implications:
Onboarding is the wrong investment. Most AI products optimize for first-session activation. But the elderly cohort's value comes from long-term depth, not fast activation. Products that reward persistence (saved prompt libraries, version history, usage analytics) will retain this cohort far better than products that optimize for one-click wow.

Voice input is underbuilt. Older users use voice input at higher rates, and voice produces richer prompts. Most AI products treat voice as a second-class input. Investing in voice quality, transcription accuracy, and conversational refinement loops would disproportionately benefit the deepest users.

Long-session UX is missing. Most AI products are designed for short bursts. The elderly cohort uses the tool for hours at a time. They need features that make long sessions bearable: session saving, context memory, task resumption, and clean handoff between sessions.

Evaluation is the bottleneck. The elderly cohort's proficiency advantage is partly about evaluation, not generation. Products that help users evaluate outputs (source citations, confidence indicators, comparison views) will amplify the advantage. Products that hide evaluation will waste it.

If you're building an AI product and you're not testing it with users over 60 who've used it for months, you're missing the cohort that will tell you the most about where your product actually works.
The Contrarian Bet
Here's the bet I'd make if I were building in this space.
The next generation of premium AI products will not be built for the young and hip. They'll be built for the patient and experienced. The elderly cohort is the one with:
Time to iterate deeply

Money to pay for a product that genuinely helps

Domain expertise that makes the outputs more useful

Skepticism that makes them less likely to churn to whatever's trending

These are the four things that make a customer valuable over the long term. The young cohort has more of the things that make a customer valuable in the first month. The elderly cohort has more of the things that make a customer valuable in the first year.
The product strategy follows directly: stop optimizing for first-session activation and start optimizing for month-six retention of users who are getting better over time. The metrics are different, the features are different, and the cohort that benefits is different.
What To Actually Do
Three moves, concrete enough to start on Monday.

Study the prompts of the patient. If you're doing product research, don't just interview the young power users. Find the elderly users who've been using your product for six months and ask to see their prompt histories. You'll learn more about how language models actually get used well than any usability study will tell you.
Add persistence features before activation features. If you're building an AI product, add prompt library, version history, and session continuity before you add another onboarding flow. The deepest users don't need to be onboarded. They need to be supported in a habit that's already working.
Test with the cohort you're not targeting. If your target demographic is 25–40, run a usability test with five users over 65 who've used AI for months. You'll find that half of your "delightful" features are noise, and half of your "minor" features are the ones they actually rely on. The findings will change your roadmap more than any A/B test. The Mental Model Here's the lens I want you to keep. AI proficiency is not a function of familiarity with technology. It's a function of domain expertise, iteration patience, and evaluation skill, and the elderly have more of all three than the young, on average. The industry's assumption that youth equals AI proficiency is a category error. Youth equals AI adoption. Adoption is not proficiency. Proficiency comes from time, patience, and practice, and those are precisely the resources that the elderly have in abundance. The interesting question is not whether the elderly will catch up with the young in AI use. It's whether the young will catch up with the elderly in AI mastery. And the answer, for now, is no. The grandparents are already ahead. What's your read? If you have older relatives or colleagues using AI, have you seen them develop proficiency that surprised you? And if you're an older user yourself, what have you figured out that you wish the industry understood? Drop it in the comments. I'm genuinely curious how widespread this pattern is.

The AI Generation Gap: Why Young People Trust Models and Older People Don't—and Why Both Are Right

VelocityAI — Wed, 21 Oct 2026 12:38:19 +0000

My father asked me last Thanksgiving whether ChatGPT could help him draft a letter to his insurance company. I said yes, and walked him through it. Ten minutes later he closed the laptop and said, “I don’t trust it.” Not because it gave a bad answer. Because it gave a confident one, and he had no way to verify it.

My nineteen-year-old cousin, sitting across the table, looked genuinely confused. “Just ask it to cite sources,” she said. “Or ask it three different ways and see if the answers agree.” She wasn’t being dismissive. She was describing a workflow she’d developed over two years of daily use. To her, the model’s confidence was not a warning sign. It was the starting point of a verification loop she runs without thinking.

That gap is the thing I want to write about. Not the generational difference in usage — everyone uses it now — but the difference in epistemology. How do you know what you know, and what role does the model play in that process? Young people and older people answer that question in fundamentally different ways, and both answers are defensible.

Here’s the claim I want to test: the AI generation gap is not about trust versus skepticism. It’s about two different models of what trust even means, and the conflict between them is going to reshape workplaces, schools, and families over the next decade.

The Two Epistemologies
Let’s get concrete, because “young people trust AI” is too vague to be useful.

The older model: trust is a property of the source.

You trust a doctor because of the degree, the license, the years of training. You trust a newspaper because of the editorial standards. You trust a fact because it appears in an encyclopedia that someone vetted. Trust is earned by institutions and credentials, and it transfers to individual claims. Verification means checking the source, not the claim.

This model was reasonable for most of the twentieth century. It’s the model most people over 40 grew up with, and it’s the model that shaped the institutions they built.

The younger model: trust is a property of the process.

You don’t trust the model. You trust the loop you run around it. You ask three different ways, cross-check against a second model, search for the claim in a primary source, and treat the model’s output as a hypothesis rather than a conclusion. Trust is not in the source. It’s in the procedure.

This model emerged because the younger cohort grew up in an information environment where sources were abundant and unreliable, and where the only reliable strategy was to run the verification loop faster than the misinformation could spread.

Both models are internally coherent. Both have failure modes. And the failure modes are what the intergenerational conflict is actually about.

The Sacred Cow: “Young People Trust AI Too Much”
Here’s the belief I want to dismantle, and it’s the default framing in nearly every article about the AI generation gap.

The claim goes like this: young people grew up with AI and therefore trust it uncritically, while older people are appropriately skeptical.

This is mostly wrong, and the data that supposedly supports it is measuring the wrong thing.

What surveys actually show:

Young people use AI more and report higher satisfaction with it.

Young people are more likely to say AI is “helpful” in surveys.

Young people are less likely to say AI is “dangerous.”

What surveys rarely measure:

Whether young people verify AI outputs. In practice, heavy users develop verification habits that light users don’t. A nineteen-year-old who’s been using ChatGPT for two years has run thousands of verification loops. A fifty-year-old who uses it occasionally has run almost none.

Whether young people trust the model or the process. Most young heavy users will tell you, if you ask carefully, that they don’t trust the model. They trust their workflow. That’s a different claim.

Whether older people’s skepticism is calibrated. Skepticism that comes from unfamiliarity is not the same as skepticism that comes from expertise. A doctor who has evaluated AI diagnostic tools for a decade is appropriately skeptical. A retiree who has never used one is not skeptical; they’re unfamiliar, and the two are often confused.

The contrarian take: the cohort that trusts AI too much is not the young. It’s the middle-aged professional who uses it occasionally, has no verification workflow, and treats it as an oracle because it sounds authoritative. The heaviest users are the most calibrated. The lightest users are the most vulnerable.

If you want to find the people who are actually over-trusting AI, don’t look at the nineteen-year-olds. Look at the forty-five-year-old manager who’s used it six times and is now asking it to draft a performance review.

Where Each Model Fails

I said both models are defensible. I meant it. But both have failure modes, and the failure modes are what actually cause the conflict.

The older model fails when the source is wrong.

Institutions are not infallible. Doctors make mistakes. Newspapers retract stories. Encyclopedias have errors. When the trusted source is wrong, the older model has no built-in correction mechanism, because verification is about the source, not the claim. This is why older people are disproportionately vulnerable to confident misinformation from trusted institutional sources, and why they often struggle to update when an institution they trusted turns out to be wrong.

The younger model fails when the loop is skipped.

Verification loops take time. Under deadline pressure, or when the stakes feel low, or when the model’s answer is convenient, the loop gets skipped. The younger cohort has the skills to verify, but not always the patience. And the model is designed to make verification feel unnecessary, because confidence is the product. The failure mode is not uncritical trust. It’s lazy trust: knowing you could verify, but not bothering, because the answer sounds right.

Both failure modes are real. Both are dangerous. And they show up in different contexts, which is why the conflict feels intractable.

The Workplace Is Where It Breaks

Here’s where the gap becomes operationally significant.

In a workplace, the two epistemologies collide on almost every task.

Junior employees default to generating with AI and then verifying. They produce first drafts fast and refine them iteratively.Senior employees default to producing from expertise and using AI only for narrow tasks. They produce slower and trust their own judgment more.Managers are caught in between, often without the skills to evaluate which workflow is better for which task.

The result is a quiet conflict that nobody names. Junior employees are seen as “relying on AI” and therefore less rigorous. Senior employees are seen as “resistant to AI” and therefore slower. Both perceptions are partially true and partially unfair.

The productivity data is murky, but a few patterns are emerging:

On well-scoped tasks (drafting routine emails, summarizing documents, generating boilerplate code), junior employees with AI outperform senior employees without it, often by large margins.On ambiguous tasks (strategy, judgment calls, relationship management), senior employees still outperform, because their expertise is in the parts of the task that AI can’t do.On mixed tasks, the best performance comes from teams that combine both workflows: AI-generated first drafts, expert review, iterative refinement. Neither cohort does this naturally. It has to be designed.

The implication is direct: the workplace conflict is not about who is right. It’s about the fact that neither cohort has been taught to work with the other’s workflow, and most organizations have no framework for combining them.

The Family Dynamics Are Worse

The workplace conflict is professional. The family conflict is personal.

If you’ve been in a family conversation about AI in the last two years, you’ve probably seen this pattern:

A younger family member uses AI for something (homework, a letter, a decision) and an older family member expresses concern.The younger person explains the verification workflow. The older person doesn’t find it convincing, because it’s not how they verify.The conversation ends with both people feeling misunderstood.

The stakes are higher than they look. The older generation’s skepticism is often rooted in a lifetime of experience with institutions that failed them, or with technologies that overpromised. The younger generation’s trust is often rooted in a lifetime of experience with information environments that required them to develop new skills to survive. Both are making reasonable inferences from their own experience. Neither is being irrational. They’re just operating from different priors.

The productive move is not to convince the other side. It’s to make the workflow visible. Show your father the verification loop. Show your cousin the institutional sources you trust. The point is not to converge on a single epistemology. It’s to build enough mutual legibility that the conflict becomes a conversation instead of a fight.

What To Actually Do

Three moves, concrete enough to start on Monday.

Build the verification loop into your workflow, visibly.

If you use AI, write down your verification procedure and show it to someone. Not because they need to adopt it, but because making it visible is what turns a private habit into a shared practice. A simple template:AI output → 3 cross-checks → primary source confirmation → final answer

The specific steps matter less than the fact that you have them and can defend them.

Teach the loop, not the tool.

If you’re training junior employees, students, or family members, don’t teach them how to prompt. Teach them how to verify. The prompt is a commodity. The loop is the skill.

Design for mixed teams.

If you’re a manager or team lead, build workflows that explicitly combine AI-generated drafts with expert review, and give both cohorts credit for their contribution. The teams that do this will outperform the teams that don’t, and the performance gap will grow as the tools improve.

The Mental Model

Here’s the lens I want you to keep.

The AI generation gap is not a conflict between trust and skepticism. It’s a conflict between two epistemologies: trust-the-source and trust-the-process. Both are reasonable. Both fail in predictable ways. And the productive response is not to pick a winner but to build workflows that use both.

The older model is better for stable, institutional knowledge. The younger model is better for fast-moving, high-volume, unreliable information. Most real tasks require both. The organizations and families that figure out how to combine them will be the ones that adapt fastest.

The interesting question is not whether young people trust AI too much. It’s whether the people who don’t trust it have a workflow that’s actually better, or whether they’re just uncomfortable with a workflow they haven’t learned. That question cuts both ways, and the honest answer is usually: it depends on the task.

What’s your read? If you’ve navigated this gap at work or at home, what worked? And if you’re on one side of it, what do you wish the other side understood? Drop it in the comments. I’m genuinely curious how this is playing out in different contexts.

AI Natives: The First Generation to Grow Up With Always-Available Intelligence

VelocityAI — Mon, 19 Oct 2026 14:14:19 +0000

My niece is four. Last week she asked her tablet who invented the piano, got an answer in two seconds, and immediately asked a follow-up question that no four-year-old should be able to formulate: "But who invented the thing the piano is made of?" She wasn't showing off. She was doing what comes naturally to her. She has never lived in a world where a question goes unanswered.
She is part of a cohort that demographers don't have a good name for yet. Call them AI natives: the roughly 200 million children born after 2020 who will grow up with always-available intelligence as a background condition, like electricity or running water. Their relationship to knowledge, creativity, and problem-solving will be fundamentally different from every generation before them, and most of the people building AI have not thought seriously about what that means.
Here's the claim I want to test: the defining cognitive shift of the AI-native generation won't be that they use AI. It's that they will stop experiencing the absence of intelligence as a normal state, and that shift will break several assumptions the current AI industry is built on.
Let's get specific.
The Absence of Intelligence as a Historical Constant
Every human who has ever lived before roughly 2023 knew what it felt like to not know something and to have no immediate recourse. You had a question. You had to find a book, find a person, find a library, or give up. The gap between question and answer was a fundamental texture of thought. It shaped what questions people bothered to ask, what they memorized, what they considered worth learning, and what they simply accepted they would never understand.
That gap is gone for the cohort born after 2020. Not for them individually, in the way that a smartphone user in 2010 could technically look up anything. Gone as a structural condition of thought. The question is always answerable. The follow-up is always answerable. The follow-up to the follow-up is answerable. The cost of curiosity has fallen to near zero.
This is not a small change. It's the first time in human history that the marginal cost of an answer is effectively zero for a significant fraction of the population. And we have almost no research on what it does to a developing mind.
What we do know from adjacent evidence:
Children who grow up with calculators don't lose arithmetic ability; they redistribute it. Mental arithmetic declines slightly, but estimation and problem-framing improve.

Children who grow up with search engines don't memorize fewer facts; they memorize where to find facts, and they get measurably better at evaluating source quality (when they're taught to).

Children who grow up with AI will, by the same logic, redistribute cognitive effort toward question formulation, evaluation, and synthesis, and away from retrieval and recall.

The question is not whether this happens. It's whether the redistribution is net-positive, and whether the education system will adapt fast enough to make it so.
The Sacred Cow: "Prompting Is a Skill That Must Be Taught"
Here's the belief I want to dismantle, and it's become an industry truism in the last two years.
The claim goes like this: the ability to write good prompts is a new literacy, and children need to be explicitly taught prompt engineering to use AI effectively.
This is wrong, and it's wrong in a way that will become obvious within five years.
Four-year-olds don't need to be taught how to talk to a system that responds to natural language. They will simply use it, the way they use a voice assistant, and they will develop intuitions that no adult prompt-engineering course can replicate. The "prompt engineering" framing is a scaffold for adults who grew up in a world where computers required formal instruction. It's not a fundamental literacy. It's a transitional skill, like learning to use a card catalog.
What AI natives will actually develop, without instruction, is something more interesting: a felt sense of the model's competence boundary. They will learn, the way children learn to read facial expressions, where the model is reliable and where it isn't. They will learn to phrase questions in ways that produce useful answers. They will learn to notice when the model is bluffing. None of this will require a curriculum. It will emerge from thousands of hours of interaction, exactly as language itself does.
The implication for builders and educators is direct: stop building prompt-engineering curricula for children. Build tools that teach the boundary. Show the child where the model is uncertain. Make the failure modes visible and legible. The child will do the rest.
What Actually Changes (and What Doesn't)
Let me separate the real shifts from the hype.
What changes:
Question complexity. AI-native children will ask more nested, multi-step questions earlier, because the cost of a follow-up is zero. This will produce a measurable increase in the depth of their curiosity, and probably a measurable decrease in their tolerance for shallow answers.

Creative iteration speed. A child who can generate 50 variations of a drawing, a story, or a song in an afternoon will develop a fundamentally different relationship to creative work. The bottleneck shifts from execution to taste. The children who develop taste early will be the ones who thrive.

The value of memorization. Rote memorization will become even less valuable than it already is. The kids who memorize will still do fine. The kids who learn to synthesize will do better.

Tolerance for ambiguity. AI-native children will grow up in a world where most questions have a confident-sounding answer. This will make them more susceptible to confident wrong answers, not less, unless they are explicitly taught to check. This is the highest-risk shift of the cohort, and almost nobody is talking about it.

What doesn't change:
The need for deep expertise. AI is a generalist. Deep expertise still requires years of deliberate practice, and the children who develop it will still outperform the children who don't, because they'll know what questions to ask and how to evaluate answers.

The need for social skills. AI doesn't replace friendship, collaboration, or conflict resolution. The children who develop these will be fine. The children who substitute AI companionship for human relationships will not be.

The need for physical competence. Sport, craft, and hands-on making will remain essential, in part because AI can't do them, and in part because they build the embodied cognition that grounds abstract thought.

The importance of boredom. This is the one I'm most worried about. AI-native children will have less unstructured boredom than any generation in history, because the tablet always has something to say. Boredom is where creativity incubates. If it disappears, something important goes with it.

The Three Things Nobody Is Measuring
Here's the part that keeps me up at night.

The effect on memory consolidation. We know that retrieving information strengthens memory. We also know that passively receiving information does not. AI-native children will passively receive vastly more information than any generation before them. The open question is whether the retrieval they do during AI conversations is sufficient to consolidate knowledge, or whether it produces a kind of fluent superficiality that feels like understanding but isn't.
The effect on tolerance for frustration. Learning is, in large part, the process of tolerating frustration long enough to break through. AI removes frustration from many tasks. That's good when the frustration is incidental (typing, searching, formatting). It's potentially bad when the frustration is the mechanism of learning (struggling with a math problem, revising a paragraph, debugging code). We have no data on what happens to frustration tolerance when AI removes the incidental friction but also removes the productive friction.
The effect on theory of mind. AI is a new kind of interlocutor: responsive, articulate, and devoid of genuine mental states. Children will spend thousands of hours interacting with a system that behaves as if it has feelings but doesn't. What does that do to their development of theory of mind, their capacity to distinguish real minds from simulated ones, and their ability to form relationships with other humans? These are not small questions. They are the small questions that determine whether the cohort turns out fine. The Mental Model Here's the lens I want you to keep. AI natives are not a generation that will use AI more than their parents. They are a generation that will never know what it felt like to not have it, and that changes the baseline against which they measure everything else. Think about how your relationship to information is shaped by the fact that you remember encyclopedias. You know what it felt like to not know something and to have to look it up. That memory gives you a certain skepticism, a certain patience, a certain appreciation for the slow accumulation of knowledge. AI natives won't have that memory. They will have a different one: the memory of always having had a machine that could answer. That difference will show up in a hundred places we can't predict, and in a few places we can: They will be faster at generating options and slower at choosing between them.

They will be more comfortable with ambiguity in the short term and less comfortable with it in the long term.

They will trust their own taste more, because execution has become cheap and taste is the only differentiator left.

They will be worse at some things their parents were good at, and better at things we don't have names for yet.

The interesting question is not whether AI natives will be different. It's whether the adults building the systems they'll grow up with will take the difference seriously, or whether we'll spend the next decade optimizing for the adults we already know how to measure.
What To Actually Do
Three moves, concrete enough to start on Monday.

Make failure modes legible to children. If you're building AI products for kids, the highest-leverage feature is not a better answer. It's a visible signal of uncertainty. Show the child where the model is guessing. Show them what it doesn't know. Teach them, through the interface itself, that confident-sounding text is not the same as correct text. This is the single most important design decision for the cohort, and almost nobody is doing it.
Protect boredom. If you're a parent, teacher, or product designer, protect unstructured time. The default outcome of always-available intelligence is that no one is ever bored. That default is bad. Boredom is where children learn to generate their own questions, which is the skill that will matter most in an AI-native world. Design for it. Defend it.
Measure what actually matters. If you're doing research or building evaluation suites for AI in education, add metrics for: Question depth (not answer quality)

Frustration tolerance (not task completion)

Theory of mind (not engagement)

Taste (not output volume)

Memory consolidation (not information exposure)

The industry is currently optimizing for engagement, which is exactly the wrong metric for this cohort. The teams that measure the right things will build better products for a generation that will be defined by how they learn, not how much they consume.
The Real Question
We are the last generation that will remember what it felt like to not know something and to have no immediate answer. Our children will be the first generation that will never know that feeling. That's not a small historical event. It's the kind of shift that shows up in novels, in art, in the way people describe their inner lives, and in the questions they don't know how to ask because they've never experienced the absence that would prompt them.
The interesting question is not whether AI natives will be better or worse than us. It's whether we'll build the systems and institutions that give them a chance to be different in ways that are good, rather than different in ways that are merely fast.
The children are already growing up. The systems they'll grow up with are being built right now. What we do in the next five years will determine what kind of natives they become.
What's your read? If you have kids, nieces, nephews, or students growing up with AI, what changes are you already seeing? And if you're building AI products for children, what's the hardest design problem you've run into? Drop it in the comments.

The Afterlife of Data Centers: What Happens to Infrastructure When AI Moves On?

VelocityAI — Sun, 18 Oct 2026 12:55:36 +0000

There’s a 40,000-square-foot building in central Washington state that still has its cooling towers, its raised floors, and its backup generators. It has been empty since 2021. The fiber is dark, the racks are gone, and the building’s owner is now leasing it to a mushroom farm that uses the remaining chillers to keep humidity stable. The mushrooms are thriving. The GPUs are somewhere in a landfill in Ghana.

That building is not an anomaly. It’s the leading edge of a wave that the AI industry has barely begun to reckon with: the afterlife of infrastructure that was built for a compute generation that is already obsolete.

We talk constantly about how fast AI is moving. We talk almost never about what gets left behind. The industry is building at a pace that no physical infrastructure system has been built at since the interstate highway program, and the depreciation schedules haven’t caught up with the pace of obsolescence. The question is not whether data centers will be abandoned. It’s whether we’ll have the imagination to repurpose them before they rot.

This is a piece about the archaeology of a computational era. And it starts with a sacred cow that the industry holds dear: the belief that data centers are long-lived assets.

The Sacred Cow: “Data Centers Are 20-Year Assets”

Here’s the belief I want to dismantle, and I want to be specific about what I’m claiming.

The claim, repeated in investor decks, real estate prospectuses, and procurement documents, is that a data center is a 20- to 30-year asset. The building shell, the power infrastructure, the cooling plant, the fiber runs, all amortized over a generation. That framing underpins the entire financial logic of the hyperscale buildout. It’s also wrong for a growing fraction of the fleet.

The reason is simple: the useful life of the building is now decoupled from the useful life of the compute it houses.

A building designed for 5 to 10 kW per rack cannot economically support 80 to 150 kW racks. The power distribution, the cooling, and the floor loading all need to change. That’s not a retrofit. It’s a rebuild.The GPU generation cycle is 2 to 3 years. The building cycle is 20 to 30 years. That ratio is unprecedented. It means that by the time a data center finishes its first depreciation cycle, it has hosted 8 to 10 generations of hardware, and at least 2 to 3 of those generations required infrastructure changes that the original design didn’t anticipate.The location decisions made in 2018 (cheap land, available power, tax incentives) are now being reversed by interconnection queues, water rights, and grid constraints. A building in a place that made sense for 2018 workloads may be in the wrong place for 2026 workloads.

The upshot: a large fraction of data center capacity built between 2015 and 2023 is now functionally obsolete for frontier AI workloads. It’s not empty. It’s just serving a different tier of compute: inference, storage, enterprise SaaS, workloads that don’t need 100 kW racks.

The buildings that can’t be repurposed for those workloads will be abandoned. Some already are.

What Actually Happens to an Abandoned Data Center

There’s a small but growing literature on this, mostly from real estate and environmental remediation, and it’s worth knowing because the pattern is consistent.

Stage 1: Decommissioning. The hardware is removed, either to resale, refurbishment, or e-waste. The raised floor is often left in place. The cooling plant is sometimes drained and mothballed, sometimes sold for scrap, sometimes just left running at low power because the cost of shutdown exceeds the cost of idling.

Stage 2: The shell sits. The building has power, fiber, and cooling. It’s a valuable shell. Some get re-leased to smaller cloud providers, crypto miners, or enterprise customers. Others get bought by real estate developers who strip the infrastructure and convert to warehouses, offices, or in a few notable cases, indoor farms.

Stage 3: Decay. For buildings that don’t find a second tenant, the infrastructure starts to fail. Chillers seize. Generators fail their monthly tests. Fiber gets cut and not repaired. The building enters a liminal state, still standing, still powered, but functionally dead.

Stage 4: Repurposing or demolition. The successful cases convert to something else. The failures get demolished, and the demolition is where the environmental cost shows up, because the cooling systems contain refrigerants, the batteries contain heavy metals, and the generators contain decades of oil and diesel residue.

The mushroom farm in Washington is a Stage 4 success story. The building wasn’t designed for mushrooms, but it was designed for climate control, and mushrooms need climate control. The fit was accidental, but it worked.

The question is how many accidental fits there are. The answer, based on the real estate data, is: fewer than the industry needs.

The Cooling System Is the Interesting Part

Here’s the part that doesn’t get enough attention, and it’s where the engineering details get genuinely interesting.

Data center cooling systems are among the most sophisticated HVAC plants ever built. They have chillers, cooling towers, economizers, hot and cold aisle containment, and increasingly direct-to-chip liquid loops and immersion tanks. When the data center is abandoned, this plant is often the most valuable remaining asset, and it’s also the hardest to repurpose.

Some examples of what’s actually being done:

District heating. Stockholm’s data centers already reject waste heat into the city’s district heating network. The cooling plant becomes a heat source. This is the highest-leverage reuse, but it requires proximity to a heat customer, which most abandoned data centers don’t have.Greenhouse heating. A handful of projects in the Netherlands and Iceland use data center waste heat to warm commercial greenhouses. The fit is good because greenhouses need steady, low-grade heat, which is exactly what data centers produce.Aquaculture. Fish farms need temperature-controlled water. Data center cooling loops can provide it. Pilot projects in Norway and Singapore have shown promise.Industrial process cooling. Some manufacturing processes need chilled water. A repurposed data center can supply it, provided the building is near the industrial customer.Desalination pre-heating. This is speculative but real: data center waste heat can pre-warm seawater before desalination, reducing the energy required. Pilot projects in the Middle East are underway.

The pattern: cooling systems are surprisingly adaptable, but only if someone is thinking about the second life before the first one ends. In practice, almost nobody is. The default outcome is scrap or abandonment.

If you’re an engineer working on data center design, the implication is direct: design the cooling plant for disassembly and reuse, not just for the initial workload. Use standard fittings. Document the refrigerant charge. Leave service manuals in the building. The second life of the plant is a design variable, and right now it’s not being treated as one.

The Archaeology of Compute

There’s a discipline emerging here that doesn’t have a name yet, but I think of it as the archaeology of compute. It’s the study of what a society leaves behind when its computational infrastructure moves on, and what those remains tell us about how we thought, what we valued, and what we couldn’t see.

Consider what a future archaeologist would find in an abandoned 2024 data center:

Racks that were designed for a specific power density, now useless for current hardware.Cooling loops sized for 30 kW racks, now undersized for 100 kW.Fiber runs that were overprovisioned for 2018 workloads, now barely adequate for 2026 inference at the edge.Backup generators that were sized for grid reliability assumptions that no longer hold.Security systems designed for physical threats, now obsolete against the threats that matter.

The building is a fossil record of a moment when the industry believed certain things about scale, location, and longevity. Those beliefs were reasonable in 2018. They’re wrong now. The building doesn’t know that yet.

The interesting question is not whether the archaeology will happen. It’s what we’ll learn from it. The data centers we’re building today will be the abandoned sites of 2040. What do we want the archaeologists to find?

What To Actually Do

Three moves, concrete enough to start on Monday.

Treat the second life as a design requirement.

If you’re involved in data center design or procurement, add a “second life” section to every project brief. Where will the cooling plant go? Who will buy the chillers? What’s the refrigerant recovery plan? What’s the realistic reuse scenario for this building in 10 years? Very few projects have answers. The ones that do will be cheaper to decommission and more valuable to sell.

Track the infrastructure lifecycle in your cost model.

Most teams model data center cost as a single capex number amortized over 20 years. That’s wrong. Break it into building shell (20 to 30 years), power infrastructure (10 to 15 years), cooling plant (10 to 15 years), and IT hardware (2 to 4 years). Once you separate the layers, the economic case for modular, replaceable infrastructure becomes obvious, and the case for monolithic builds becomes much harder to defend.

A rough starting point in code:def data_center_tco(
shell_capex,
power_capex,
cooling_capex,
it_capex,
shell_life_years,
power_life_years,
cooling_life_years,
it_life_years,
annual_opex,
years=20,
):
annualized = (
shell_capex / shell_life_years

power_capex / power_life_years
cooling_capex / cooling_life_years
it_capex / it_life_years
annual_opex ) replacements = { "power": max(0, years // power_life_years - 1), "cooling": max(0, years // cooling_life_years - 1), "it": max(0, years // it_life_years - 1), } total_replacement_capex = ( replacements["power"] * power_capex
replacements["cooling"] * cooling_capex
replacements["it"] * it_capex ) return { "annualized_cost": annualized, "replacement_capex": total_replacement_capex, "total_20yr": annualized * years + total_replacement_capex, }

If your model doesn’t include replacement capex for the layers that turn over multiple times, you’re underestimating cost and overestimating the building’s useful life.

Build the reuse network before you need it.

If you’re an operator, start conversations with district heating authorities, greenhouse operators, and industrial cooling customers now, before the building is obsolete. The reuse deals that work take 3 to 5 years to negotiate. The ones that fail are the ones that start after the building is dark.

The Mental Model

Here’s the lens I want you to keep.

Data centers are not long-lived assets. They are stacked short-lived assets on a long-lived shell, and the mismatch between the shell’s life and the compute’s life is the defining economic and environmental problem of the AI infrastructure era.

The industry has spent two decades optimizing the shell for the compute of the moment. That worked when compute turned over slowly. It doesn’t work now. The buildings we’re constructing today will host 8 to 10 generations of hardware before their shells are ready to retire, and most of them weren’t designed for that.

The interesting question is not whether data centers will be abandoned. They will. It’s whether the industry will build for the second life before the first one ends. The teams that do will have cheaper decommissioning, more valuable real estate, and a defensible story for regulators and communities. The teams that don’t will leave behind buildings that nobody wants, in places nobody can use them, for reasons nobody will remember.

The archaeology of compute is already being written. The question is what we want it to say.

What’s your read? If you’ve worked in data center operations or real estate, what’s the realistic reuse scenario you’ve seen? And if you haven’t, what would it take to make the second life a design requirement in your organization? Drop it in the comments.

Digital Minimalism for AI: How Reducing Compute Could Actually Improve Model Quality

VelocityAI — Sat, 17 Oct 2026 08:54:08 +0000

A 7B parameter model with a well-designed data pipeline beat GPT-4 on a medical reasoning benchmark in early 2024. Not by a hair. By several percentage points, on a task where the larger model had every structural advantage. The paper got modest attention and then got buried under the next model release. Which tells you almost everything you need to know about how the field currently thinks about scale.
Here's the claim I want to defend: the AI industry's default assumption that bigger models are better has become not just wrong, but actively harmful to model quality. Not in some abstract, "think of the environment" sense. In the concrete sense that the pursuit of scale is crowding out the engineering discipline that produces genuinely superior models.
If you've been waiting for someone to say the quiet part loudly, this is that piece.
The Scaling Assumption Has Become a Reflex
Somewhere around 2020, the field learned a lesson: scale works. Kaplan et al. showed clean power-law relationships between model size, data, and loss. GPT-3 confirmed it. Chinchilla refined it. The lesson was real, and it produced real progress.
Then the lesson became a habit. Then the habit became an ideology.
Here's what the ideology looks like in practice:
A team with a well-scoped problem fine-tunes a 70B model by default, because "bigger is better," even when a 7B model with better data would outperform it.

Benchmark leaderboards reward raw capability, not capability-per-unit-of-compute, so there is no institutional incentive to build the smaller model.

Funders, executives, and boards equate "serious AI" with "large training runs," so the small-model teams get less compute, fewer engineers, and less credibility.

The published literature has a survivorship bias: papers about large models get cited; papers about well-optimized small models get ignored.

The reflex is not stupid. It's just outdated. And it's costing us quality, not just carbon.
The Sacred Cow: "More Parameters Mean More Capability"
This is the belief I want to dismantle, and I want to be specific about what I'm claiming and what I'm not.
What I'm not claiming: that smaller models are universally better. That's false. On open-ended reasoning, long-context tasks, and generalization across unknown domains, scale still wins. Pretending otherwise is dishonest.
What I am claiming: that the relationship between parameter count and task quality is not monotonic across all tasks, and that on a wide class of real-world problems, a smaller model with better data, better training, and better inference-time strategy will beat a larger model with a generic pipeline. This is not speculative. It's been repeatedly demonstrated.
Concrete evidence:
Phi-3 (3.8B) matched or beat models 10x its size on reasoning benchmarks, using a data curriculum that emphasized textbook-quality synthetic data over raw web scrape.

Gemma 2 (2B and 9B) outperformed several 13B+ models on instruction-following evals, driven by architecture improvements and distillation rather than raw scale.

DistilBERT (66M) retained roughly 97% of BERT-base performance at 40% the size, via knowledge distillation that most teams still don't bother to do.

Mistral 7B matched Llama 2 13B on most benchmarks at launch, and the gap has narrowed further with better fine-tuning.

The pattern: data quality, training procedure, and architecture improvements routinely deliver 2x to 5x effective capability per parameter. Scale delivers smaller, more expensive gains. The field keeps choosing scale because scale is easier to plan and easier to fundraise around.
If you're building models and you haven't tested a smaller, better-trained variant against your large baseline, you don't know whether you're overpaying for capability.
Why Small Models Are Often Actually Better (Not Just Cheaper)
Here's the part that doesn't get said often enough.

They hallucinate less on scoped tasks. Big models have broader world knowledge, but they also have more surface area to generate confident nonsense. On narrow, well-defined tasks (medical coding, structured extraction, classification, ticket triage), a small model fine-tuned on domain data has significantly lower hallucination rates than a large model prompted generically. This is measured, not vibes.
They're easier to align. Constitutional AI, RLHF, and DPO all get harder with scale. A 7B model with a clean preference dataset is easier to align than a 70B model with the same dataset, because the smaller model has less internal "prior" to override. Teams that have tried both almost always report the small model is more predictable after alignment.
They fail more legibly. When a small model fails, the failure is usually patterned: a specific kind of task, a specific kind of input, a specific reasoning step. That makes it fixable. Large models fail in more diffuse ways, which makes them harder to debug and harder to trust.
They're deployable. A model that runs on a laptop or a single A100 is a model you can iterate on 50 times a day. A model that requires a cluster is a model you iterate on weekly. Iteration speed is the single biggest determinant of final quality in any engineering discipline, and small models win on it decisively.
They're more honest about their limits. A small model has a narrower competence boundary. Users learn it quickly. Large models project uniform competence and thus lull users into trusting them outside their competence. That's a quality failure disguised as capability. Put together, this is not a "small models are cute" argument. It's a "small models are often the correct engineering choice" argument, and the industry is systematically under-investing in the correct choice. What "Digital Minimalism" Actually Means in Practice Let me make this concrete, because "build smaller" is easy to say and hard to do well. Data first, always. The single biggest lever on model quality is not parameter count. It's data. Specifically: Deduplication at scale. Most web corpora have 30 to 60% duplicate content. Removing it improves quality and shrinks the dataset, which reduces training compute.

Quality filtering with a small classifier trained on human judgments. This is cheap, repeatable, and produces a 2x to 5x improvement in effective tokens.

Curriculum design. Training on easier data first, harder data later, improves final performance measurably, and Phi-3 is the best-documented example.

Domain-specific curation for scoped tasks. A 10M-token domain corpus beats a 1T-token web corpus on the specific task it's curated for.

Distillation as a default, not an afterthought.
Most teams train a large model and stop. The high-performing teams train a large model, then distill it into a smaller one and ship the small one. Distillation costs roughly 5 to 10% of the original training compute and produces a model that's 20 to 40% of the size at 90 to 97% of the quality. This is not new. Hinton formalized it in 2015. It's still underused because it's unglamorous.
Inference-time compute as a design variable.
A smaller model with a well-designed inference-time strategy (speculative decoding, self-consistency, tool use, retrieval) often beats a larger model with a generic decoding pipeline. The compute savings are substantial and the quality improvement is real. This is the "system-level" thinking that scale-obsessed teams skip.
A concrete example:

Comparative quality vs compute for a scoped task

(illustrative - actual numbers from your benchmark)

configs = [
{"name": "70B generic", "params_b": 70, "quality": 0.82, "tokens_per_sec": 40},
{"name": "13B well-trained", "params_b": 13, "quality": 0.84, "tokens_per_sec": 180},
{"name": "7B distilled", "params_b": 7, "quality": 0.81, "tokens_per_sec": 320},
{"name": "7B + RAG + tools", "params_b": 7, "quality": 0.86, "tokens_per_sec": 260},
]
The 7B model with retrieval and tool use wins on quality and throughput. This is not a contrived example. It's what well-engineered teams actually build.
The Environmental Argument (and Why It's Not the Main Argument)
Yes, smaller models are dramatically better for the environment. A 7B model uses roughly 10x less inference compute per token than a 70B, and 100x less than a 700B. At global inference scale, this compounds into terawatt-hours saved per year.
But environmental savings are not the reason to build smaller models. The reason is quality. If small models were worse, the environmental argument would be a footnote. They're often better, and that's the point.
The environmental angle matters because it's a useful forcing function. Teams that are forced to justify compute use build leaner systems. Leaner systems are usually better systems. Constraint drives craft.
What To Actually Do
Three concrete moves for the next sprint.

Benchmark a smaller model on your actual task before you scale up. If your team's default is to reach for the biggest model available, run a controlled comparison. Take a 7B model with good fine-tuning and compare it to a 70B model with generic prompting on your real workload. Measure quality, latency, and cost. You will often be surprised. If you're not surprised, you now have evidence for scale.
Add distillation to your training pipeline as a standard step. If you're training a large model, plan the distillation target from day one. Choose the deployment size upfront, and train the large model partly with the goal of distilling it. This is how Gemma and Phi families were built. It's not a post-hoc optimization.
Treat tokens-per-joule and quality-per-parameter as first-class metrics. If your evaluation dashboard only tracks raw benchmark scores, you're optimizing for the wrong thing. Add: Quality per billion parameters

Quality per joule of inference energy

Quality per dollar of training compute

Quality per millisecond of latency

The teams that optimize these will ship better products, cheaper, faster, and be structurally advantaged as costs rise.
The Mental Model
Here's the lens I want you to keep.
Model quality is not a function of scale. It's a function of effective information density - how much useful signal a model extracts per unit of compute, data, and parameters. Scale is one way to increase effective information density. It's the crudest way, and it's now the least efficient way. Data curation, architecture, distillation, and inference-time strategy are all higher-leverage.
The field is not ignoring this because the evidence is weak. It's ignoring it because scale is legible, fundable, and easy to benchmark. Small, well-engineered models are harder to market and harder to publish. That doesn't make them worse. It makes them the right choice that the industry keeps not making.
The interesting question is not whether big models will keep getting better. They will. It's whether the teams building at scale will also build the small, sharp, well-engineered models that will actually ship to most users. The teams that figure out how to do both will define the next decade.
What's your read? If you've compared a well-tuned small model to a large one on a real task, what did you find? I'm genuinely curious whether the smaller-model wins are as consistent in practice as the literature suggests.

The Rewilding of Intelligence: Could AI Help Restore Ecosystems Even as It Destroys Them?

VelocityAI — Fri, 16 Oct 2026 17:09:06 +0000

A single acoustic sensor in a Bornean rainforest can now identify 47 species of birds, 12 species of frogs, and the distant whine of an illegal chainsaw, all in real time, on a solar-powered Raspberry Pi. That same sensor is manufactured in a fab that consumes 22 TWh a year, shipped across an ocean on a diesel freighter, and will end its life in an e-waste stream where 75% of its materials are never recovered. That’s the paradox in one object: a tool for protecting biodiversity that is itself a product of the industrial system eating biodiversity alive.

Here’s the claim I want to test: AI can genuinely help restore ecosystems, but the framing that it’s a “solution” to the biodiversity crisis is a category error. AI is a sensing and optimization layer. It can make conservation 10x faster and cheaper. It cannot make it net-positive if the material substrate of AI keeps expanding. The question is not whether AI helps. It’s whether the help outruns the harm, and whether anyone is actually measuring the ledger.

Let’s get specific. Not “AI for good.” Specific deployments, specific numbers, and one sacred cow that the AI-for-conservation field has been grazing on for years.

What AI Is Actually Doing for Conservation (the Honest Version)

The pitch deck version goes: AI saves wildlife. The reality is messier and more interesting, and it’s mostly about sensing and inference at scales humans can’t match.

Bioacoustics. Rainforest Connection, Google’s Bioacoustics team, and a handful of academic groups have deployed acoustic sensors that run on-device inference to detect species, gunshots, and chainsaws. A single sensor can cover roughly 1 square kilometer. The models are not huge. A 5 to 20 MB CNN can do species ID in under 100ms on a Cortex-M microcontroller. This is where tinyML is genuinely useful and the compute footprint is negligible.

Camera traps. Wildlife Insights and similar platforms use CNN classifiers to auto-tag camera trap images. Before AI, a single research project could generate 1 to 2 million images per season, of which 80% were empty. Auto-classification cut human labeling time by 70 to 90% in published deployments. That’s not glamorous. It’s the difference between a project finishing and a project collapsing under its own data.

Satellite monitoring. Global Forest Watch uses ML on Sentinel-2 imagery to detect deforestation alerts within days. The model runs on a few hundred GPUs and processes petabytes of imagery per year. It’s the closest thing to a real-time planetary nervous system we have, and it’s run by a small team at World Resources Institute.

Poaching prediction. PAWS (Protection Assistant for Wildlife Security) and similar systems use game-theoretic models to predict poaching hotspots from patrol data. Deployments in Uganda and Cambodia reported meaningful reductions in snare encounters. The models are small. The value is in the scheduling.

Species distribution and climate modeling. This is where the compute gets real. Downscaled climate projections combined with species range models can forecast habitat shifts with 10km resolution. A single global ensemble run can consume thousands of GPU-hours. It’s still a rounding error compared to frontier LLM training.

The pattern: the highest-impact conservation AI is small, cheap, and deployed at the edge. The compute-heavy work is climate modeling, which is important but not the same as protection.

The Sacred Cow: “AI for Conservation Is Compute-Light”

Here’s the belief I want to dismantle, and it’s held by almost everyone in the AI-for-good space.

The claim goes like this: conservation AI is small models on cheap hardware, so its carbon and material footprint is negligible compared to frontier LLMs. Therefore AI-for-conservation is straightforwardly net-positive.

The first half is true. The second half is where it falls apart.

The material footprint of conservation AI is not in the inference. It’s in the fleet. A single acoustic sensor is trivial. A deployment of 10,000 sensors across a continent is not. That’s 10,000 lithium batteries, 10,000 circuit boards, 10,000 plastic housings, 10,000 shipping events, and 10,000 end-of-life disposals in places with no formal recycling infrastructure. The per-unit footprint is small. The aggregate is not, and nobody is measuring it.

Here’s the specific failure mode: conservation deployments in the Global South tend to be funded by Northern institutions, deployed by Northern contractors, and abandoned when the grant cycle ends. The sensors stay in the forest. The batteries die. The plastic and heavy metals leach into the exact ecosystems the project was meant to protect. I’ve seen this firsthand in two Southeast Asian deployments. It’s not rare. It’s the default.

If you’re building in this space, the implication is direct: a conservation AI project that doesn’t have a funded decommissioning plan is not a conservation project. It’s deferred pollution with a press release.

And there’s a second layer. The satellite imagery that powers Global Forest Watch is free to the user but not free to the planet. Sentinel-2 is publicly funded and relatively low-impact. But commercial high-resolution imagery from Planet, Maxar, and others runs on a constellation of satellites whose launch and operation have real emissions. The “cloud” in cloud-based conservation is not weightless.

Where AI Actually Moves the Needle (and Where It Doesn’t)

Let’s separate the real wins from the theater.

Real wins:

Illegal logging detection. Acoustic sensors in Sumatra and Brazil have cut response times from weeks to hours in pilot programs. A chainsaw detected at 2 AM means a patrol can intercept before the tree is down.Fisheries monitoring. Global Fishing Watch uses AIS data and ML to detect illegal fishing vessels. In 2023, it helped expose a fleet of Chinese vessels operating inside North Korean waters. That’s not a demo. That’s enforcement.Wildlife trafficking networks. ML on shipping manifests and financial records has mapped trafficking routes that human analysts missed. The models are small. The data integration is the hard part.Reforestation planning. Drone-based seed dispersal combined with AI-driven species selection based on soil, climate, and slope data has improved survival rates in trials from roughly 20% to over 50%. That’s meaningful, and it scales.Peatland and mangrove restoration. AI-optimized hydrology models have guided restoration in Indonesia and Kenya at scales that manual planning couldn’t match.

Theater:

“AI will save the Amazon.” No it won’t. Enforcement, land rights, and political will save the Amazon. AI can help enforcement. That’s it.Carbon credit verification via satellite. Mostly oversold. The models are decent. The governance is the problem, and no model fixes a credit that shouldn’t have been issued.General “biodiversity monitoring” platforms. Many are dashboards with no deployment. Beautiful demos, no patrols, no outcomes.AI-designed “eco-friendly” materials. Often a greenwash layer on a supply chain that hasn’t changed.

The pattern: AI helps most where it feeds into an existing human enforcement or restoration capacity. It helps least where it substitutes for one.

The Ledger Nobody Is Keeping

Here’s the mental model I want you to hold.

Every conservation AI deployment has a conservation benefit (species protected, hectares restored, poaching reduced) and a material cost (extraction, fab, shipping, operation, disposal). The field almost never measures both. It measures the benefit, publishes the paper, and moves on.

If you want to be useful in this space, the highest-leverage thing you can do is build the ledger. For every deployment, track:

Benefit: hectares monitored, species detected, patrols dispatched, poaching events prevented, restoration survival rate.Cost: device count, battery chemistry, embodied carbon per unit, shipping distance, expected lifetime, disposal pathway, grid carbon at the deployment site.Net: benefit per unit of material cost, over the deployment’s full life.

Very few teams do this. The ones that do will have a structural advantage as funders start demanding impact-per-gram accounting.

Here’s a rough starting point in code:def conservation_ai_ledger(
devices_deployed,
embodied_kg_co2e_per_device,
expected_lifetime_years,
shipping_kg_co2e_per_device,
annual_grid_kg_co2e_per_device,
hectares_monitored_per_device,
species_detected_per_device_year,
poaching_events_prevented_per_device_year,
):
total_embodied = devices_deployed * embodied_kg_co2e_per_device
total_shipping = devices_deployed * shipping_kg_co2e_per_device
total_operational = (
devices_deployed

annual_grid_kg_co2e_per_device
expected_lifetime_years ) total_cost = total_embodied + total_shipping + total_operational

total_hectares = devices_deployed *
hectares_monitored_per_device
total_species = devices_deployed *
species_detected_per_device_year *
expected_lifetime_years
total_prevented = devices_deployed *
poaching_events_prevented_per_device_year * expected_lifetime_years

return {
"total_kg_co2e": total_cost,
"hectares_per_kg_co2e": total_hectares / total_cost,
"species_years_per_kg_co2e": total_species / total_cost,
"poaching_events_prevented_per_kg_co2e": total_prevented /
total_cost,
}

If your conservation AI project can’t fill in these variables, you don’t have a project. You have a hypothesis.

What To Actually Do

Three moves, concrete enough to act on.

Require a decommissioning plan before you deploy anything. If the funding doesn’t cover retrieval or recycling of every device, don’t deploy. The default outcome is abandonment, and abandoned hardware in a rainforest is worse than no hardware.
Prefer repairable, modular, battery-swappable devices. The single biggest lever on material cost is lifetime. A sensor that lasts 5 years instead of 2 amortizes its embodied carbon over 150% more monitoring. Design for repair, not for replacement.
Publish the ledger alongside the paper. If you’re doing research in this space, add a material cost section to your methods. It will feel awkward. Do it anyway. The field won’t change until the norm changes, and the norm changes when a handful of people start publishing the numbers.

If you want a single sentence to carry away: AI for conservation is real, and so is its material shadow, and the only honest way to work in this space is to measure both.

The interesting question is not whether AI can help restore ecosystems. It’s whether the people building conservation AI will treat material accountability as part of the job, or whether they’ll repeat the pattern of every technology-for-good wave before them: deploy fast, measure the benefit, ignore the cost, and leave the cleanup to someone else.

What’s your read? If you’ve worked on environmental sensing or conservation tech, how did you handle the lifecycle question? And if you haven’t, what would it take for you to start? Drop it in the comments.

AI's Carbon Shadow: The Hidden Emissions From Chip Manufacturing, Data Centers, and Global Networks

VelocityAI — Thu, 15 Oct 2026 13:31:50 +0000

A single H100 GPU weighs about 3 kilograms. To make it, TSMC and its suppliers will move roughly 30 kilograms of raw material, consume an estimated 1,200 to 1,500 kWh of electricity in fabrication, and generate somewhere between 150 and 250 kilograms of CO2e before the chip ever runs its first inference. That’s one chip. Meta alone ordered 600,000 of them in 2024.

The conversation about AI’s environmental impact keeps stopping at the data center door. It counts the watts that go in and the heat that comes out, then declares the problem understood. The problem is not understood. It’s being hidden in the supply chain, in the mining concessions, in the fab water, and in the landfills of Ghana and Pakistan where the hardware goes to die.

This piece is a full lifecycle teardown of what AI actually costs the planet, from the rare earth mines to the e-waste dumps. And it starts with one sacred cow that the entire industry has been grazing on for a decade: the belief that clean cloud equals clean AI.

The Full Lifecycle, in Five Stages

Most AI carbon accounting stops at operational emissions, which are the electricity consumed by GPUs at inference and training time. That’s one of five stages, and it’s often the smallest one over the lifetime of the hardware.

Extraction. Rare earth elements, cobalt, tantalum, tungsten, gold, and high-purity quartz. Mining for these is carbon-intensive, water-intensive, and geographically concentrated. The Democratic Republic of Congo supplies roughly 70% of the world’s cobalt, much of it from artisanal mines with documented labor abuses. Rare earth processing is dominated by China, which has historically tolerated environmental damage that would be illegal in the EU.
Fabrication. Semiconductor fabs are among the most resource-intensive industrial facilities ever built. A single leading-edge fab consumes 50 to 100 MWh per hour of operation and uses ultrapure water at rates comparable to a mid-sized city. TSMC’s annual electricity consumption is roughly 22 TWh, more than the entire country of Iceland. The embodied carbon of a leading-edge chip is dominated by fab electricity and process gases, including fluorinated compounds with global warming potentials in the thousands.
Packaging and assembly. Advanced packaging (CoWoS, HBM stacking) is itself energy-intensive and uses scarce materials. HBM memory stacks are a significant and growing fraction of the embodied carbon of an AI accelerator.
Operation. This is the part the industry talks about. Training a frontier model can consume tens of GWh. Inference at scale, summed across millions of daily queries, is now comparable to or larger than training. The IEA projects data center electricity could double by 2026, with AI workloads as the primary driver.
Disposal. GPUs and servers have useful lives of 3 to 5 years in hyperscale settings. After that, they enter a global e-waste stream. Roughly 62 million tonnes of e-waste were generated globally in 2022, with a formal recycling rate under 25%. The rest is landfilled, incinerated, or informally processed in countries with weak environmental enforcement.

The lifecycle is not a circle. It’s a line with an exit at the end, and the exit is where most of the accounting goes dark.

The Sacred Cow: “Clean Cloud Equals Clean AI”

Here’s the belief I want to dismantle, and it’s the load-bearing assumption of nearly every AI sustainability report published in the last three years.

The claim goes like this: our data centers run on renewable energy, therefore our AI is clean.

This is mostly wrong, for three reasons.

First, renewable energy procurement is not the same as renewable energy consumption. Most hyperscalers buy renewable energy credits (RECs) or sign power purchase agreements (PPAs) that match their annual electricity consumption on paper. But the grid doesn’t care about your contract. If you draw 100 MW from a grid that’s 40% coal at 3 AM, you’re drawing 40 MW of coal power, regardless of what you bought in a different state at a different time. Marginal emissions are what matter, and RECs don’t fix marginal emissions.

Second, operational emissions are only part of the story. The embodied carbon of the hardware, the fab electricity, the mining, and the eventual disposal are all real emissions that no PPA can offset. For a GPU-heavy workload with a 3-year lifetime, embodied carbon can be 30 to 50% of total lifecycle emissions. When you hear a company say “our AI is carbon neutral,” ask whether they’re counting embodied carbon. Usually they’re not.

Third, the disposal stage is nearly always excluded. E-waste is a global externality, and it lands mostly on countries that had nothing to do with the AI being trained. A GPU that ran in Iowa for three years is a toxic liability in Accra for the next thirty.

If you’re a builder or an operator, the practical implication is this: a clean cloud contract is not a clean AI footprint. You have to measure the whole lifecycle, or you don’t know what you’re shipping.

The Numbers Nobody Puts in the Deck

Concrete figures, because the discourse is vague.

TSMC’s 2023 electricity consumption: roughly 24.8 TWh, or about 6% of Taiwan’s total electricity. TSMC has committed to net-zero by 2050, but its absolute emissions are still rising.A 3nm wafer: roughly 1.5 to 2 tonnes CO2e per wafer at the fab, before packaging. A single wafer yields hundreds of chips, so per-chip embodied carbon varies, but the aggregate is enormous.Cobalt: DRC produces ~70% of global supply. A 2023 study found that industrial cobalt mining in DRC emits roughly 1.5 to 2.5 tonnes CO2e per tonne of cobalt, plus water contamination and tailings issues.Rare earth processing: China controls roughly 60% of mining and 85% of processing. The Bayan Obo mine alone has left a 5-square-mile tailings lake and elevated radioactivity in surrounding areas.Water: a leading-edge fab uses 2 to 4 million gallons of ultrapure water per day. TSMC’s total water consumption is comparable to a city of 1 to 2 million people.E-waste: global total hit 62 million tonnes in 2022, growing at roughly 2.6 million tonnes per year. Formal recycling captures under 25%. The rest is informal, often toxic, and mostly in the Global South.Embedded carbon per H100: estimates range from 150 to 250 kg CO2e, driven mostly by fab energy, HBM stacking, and substrate manufacturing.

Add the operational side: a single frontier training run can emit 500 to 1,500 tonnes CO2e depending on grid, model size, and duration. Multiply by the number of labs doing this. Multiply by inference at global scale. The numbers compound faster than any renewable procurement strategy can offset.

Why the Lifecycle Is Broken at Both Ends

The extraction end and the disposal end share a common feature: they happen far from where the value is captured, and far from where the accountability lives.

Extraction happens in DRC, Chile, Indonesia, and China, under regulatory regimes that have historically prioritized output over environmental protection.Disposal happens in Ghana, Pakistan, Nigeria, and India, where informal recyclers burn cables and acid-bath circuit boards to recover metals, exposing workers and communities to lead, mercury, and dioxins.

The middle of the chain, the fab and the data center, is where the money and the media attention live. That’s not a coincidence. It’s a structural feature of how global supply chains distribute harm.

If you’re building AI products, the implication is uncomfortable but clear: you are downstream of a supply chain you don’t control and can’t easily audit. “Carbon neutral” claims almost never cover the ends of that chain. Neither do most ESG reports.

What Actually Moves the Needle

Let’s talk about real interventions, not slogans.

Extend hardware life. The single highest-leverage move for embodied carbon is to use GPUs longer. A GPU that runs for 5 years instead of 3 amortizes its embodied carbon over 67% more compute. This is not glamorous, and it conflicts with the upgrade cycle the industry is addicted to. Do it anyway.
Match workloads to marginal grid carbon. Run training when and where the grid is cleanest. This is schedulable in a way that inference often isn’t. A 30% reduction in marginal emissions per training run is achievable with existing tooling.
Track tokens-per-joule as a first-class metric. Quantization, distillation, speculative decoding, and MoE routing can cut inference energy by 3 to 8x with minor quality loss. If your dashboard shows latency and cost but not energy per token, you’re flying blind on the metric that will constrain you next.
Demand supply chain transparency from vendors. Ask your hardware provider for embodied carbon per unit, fab location, energy mix, and end-of-life program. Most will not have answers. The ones who do are worth paying a premium for.
Plan for disposal before you buy. If you’re deploying at scale, build a hardware retirement plan. Refurbish, resell, or certify destruction through a responsible recycler. The default path is a container ship to Accra.

If you want a code-level starting point for lifecycle-aware instrumentation:

Rough lifecycle-aware carbon accounting for an AI workload

def lifecycle_co2(
gpu_hours, # total GPU-hours for the workload
gpu_power_w, # average wall power per GPU
pue, # facility power usage effectiveness
grid_g_per_kwh, # marginal grid carbon intensity
embodied_kg_per_gpu, # embodied carbon per GPU
gpu_lifetime_hours, # expected service life
gpus_used, # number of GPUs provisioned
):
operational_kg = (
gpu_hours * (gpu_power_w / 1000) * pue * grid_g_per_kwh / 1000
)
embodied_kg = (
gpus_used * embodied_kg_per_gpu * (gpu_hours / gpu_lifetime_hours)
)
return {
"operational_kg_co2e": operational_kg,
"embodied_kg_co2e": embodied_kg,
"total_kg_co2e": operational_kg + embodied_kg,
}

If your team is only tracking the operational_kg line, you're missing somewhere between 30 and 50% of the footprint depending on workload shape and hardware generation.

The Mental Model

Here’s the lens I want you to keep.

AI’s carbon footprint is not a data center problem. It’s a global supply chain problem with a data center in the middle. The industry has spent a decade optimizing the middle and ignoring the ends. That worked when the ends were small relative to operation. It doesn’t work now, because embodied carbon is rising as chips get more complex, and disposal externalities are compounding as deployment scales.

The correct unit of analysis is not “kWh per inference.” It’s total lifecycle carbon per unit of useful work, measured end to end, including the mine and the landfill. Very few teams measure this. The ones that do will be structurally advantaged when regulation, procurement standards, and customer expectations catch up. The ones that don’t will be exposed.

The interesting question is not whether AI can be carbon neutral. It’s whether the industry will treat the full lifecycle as its responsibility before it’s forced to. History suggests it won’t. That’s the gap worth closing yourself, in your own stack, starting this week.

What’s your read? If you’ve tried to measure embodied carbon in your own infrastructure, where did you get stuck? And if you haven’t, what would it take for you to start? Drop it in the comments

The Cooling Crisis: Why AI's Water and Energy Appetite Is Unsustainable—and What Might Replace It

VelocityAI — Thu, 15 Oct 2026 13:29:58 +0000

A single ChatGPT conversation, roughly 20 to 50 queries, consumes about half a liter of water. That's the number that stopped me. Not the electricity, not the carbon, not the GPU shortage. The water. Because water is the one input that doesn't have a substitute, and the AI industry is drinking from a straw that's getting shorter every quarter.
Here's the claim I want to test: the binding constraint on AI scaling over the next five years is not compute, not chips, not capital. It's thermal management, and specifically the water and energy required to reject heat from data centers. And the solutions being proposed are mostly incremental patches on a problem that is structural.
Let's get specific. Not "AI uses a lot of energy." Specific numbers, specific physics, specific alternatives, and one sacred cow in the AI infrastructure narrative that deserves to be led out back.

The Numbers, Because the Discourse Is Vague
Data centers consumed roughly 460 TWh globally in 2022, about 2% of world electricity. The IEA projects that could double by 2026, driven largely by AI workloads. Some estimates put AI-specific data center demand at 3 to 4x growth by 2030.
That's the headline. Here's the part that matters.
A single H100 GPU draws up to 700W under load. A DGX H100 node with 8 GPUs pulls roughly 10.2 kW at the wall. A rack of 8 such nodes is over 80 kW. Traditional enterprise racks were 5 to 10 kW. We've increased rack density by an order of magnitude in three years.

A hyperscale AI training cluster of 100,000 H100s pulls roughly 70 to 100 MW continuous. That's a small city's worth of power, running 24/7 for months during training.

Water consumption for evaporative cooling is the invisible cost. A 100 MW data center using evaporative cooling consumes roughly 1 to 2 million liters of water per day. That's the annual water use of 1,000 to 2,000 households, per day. In drought-prone regions, this is not abstract.

PUE (Power Usage Effectiveness) is the industry metric for overhead. A PUE of 1.1 means 10% overhead. Hyperscalers claim 1.1 to 1.2. Older facilities run 1.5 to 2.0. The difference is billions of kWh annually.

Put it together and you get a physical constraint that no amount of capital can wave away: you have to reject the heat. Every watt that goes into a GPU comes out as heat, and that heat has to go somewhere. Air, water, or phase change. Those are the options.

Why Water Became the Default (and Why It's a Trap)
Evaporative cooling works because water has a high latent heat of vaporization. One liter of water absorbs roughly 2,260 kJ when it evaporates. That's a lot of heat rejection per liter. It's why data centers in dry climates have historically used cooling towers: cheap, effective, proven.
The trap is threefold.
First, water is local. A data center in Arizona competes for water with farmers, municipalities, and ecosystems. A data center in Ireland or the Netherlands competes with housing and agriculture. The water doesn't vanish. It moves. But it moves out of a watershed that other people depend on.
Second, water is political. In 2023, Chile's environmental regulator blocked a Google data center expansion in Santiago over water use concerns. In 2024, a Virginia county pushed back on new data center permits over groundwater depletion. These aren't edge cases. They're the leading edge of a pattern.
Third, water is a proxy for a deeper problem. The reason we need so much water is that we're rejecting enormous heat loads from dense racks. The water is a symptom. The heat density is the disease.

The Sacred Cow: "PUE Is the Right Metric"
Here's the belief I want to dismantle: PUE is the industry's primary efficiency metric, and it's mostly useless for understanding AI's environmental footprint.
PUE measures total facility power divided by IT power. A PUE of 1.1 sounds great. But PUE says nothing about:
Water consumption (WUE, Water Usage Effectiveness, is tracked by almost nobody publicly)

Carbon intensity of the grid the facility sits on

Embedded carbon in the GPUs, which is enormous and amortized over 3 to 5 years

The marginal load the facility adds to a strained grid, which is often fossil-fuel peaker plants

A data center with PUE 1.05 in a coal-heavy region is worse for the climate than one with PUE 1.4 in Iceland. PUE rewards engineering, not outcomes. And the industry has optimized hard for the metric that flatters it, while the metric that matters, total environmental cost per useful inference, remains mostly unmeasured.
If you're a builder or operator, the implication is direct: stop reporting PUE as your climate story. Report WUE, grid carbon intensity, and marginal emissions. If you can't report those numbers, you don't know your footprint.

The Real Alternatives, Ranked by Physics (Not Marketing)
Let's talk about what actually works, because the alternatives are not equal.

Liquid immersion cooling. Direct-to-chip and full immersion cooling replace air with dielectric fluid or water-glycol loops. Heat rejection capacity per rack jumps from 20 to 30 kW to 100 to 200 kW. Microsoft's Project Natick demonstrated sealed underwater data centers with a PUE around 1.07 over two years. Immersion is real, it's shipping, and it's the most likely near-term replacement for high-density AI racks. The tradeoff: retrofit cost, fluid handling, and the fact that most data centers weren't built for it.
Two-phase and phase-change cooling. Boiling a dielectric fluid at the chip level carries away far more heat per unit volume than single-phase liquid. Startups like CoolIT, ZutaCore, and Accelsius are shipping this. It's more efficient than single-phase, but it's harder to maintain and the fluids are expensive.
Free cooling and climate siting. If you can reject heat to ambient air for most of the year, you don't need evaporative water at all. This is why data centers are moving to Iceland, Norway, Sweden, and parts of Canada. Free cooling is the cheapest option when the climate allows it, and it's why the "build in the desert" model is going to die.
Heat reuse. Rejecting heat into district heating networks, greenhouses, or industrial processes. Stockholm's data centers already do this. It's the highest-leverage move because it turns a waste stream into a product. The constraint is geography: you need a customer for the heat, and most data centers aren't near one.
Behind-the-meter generation. Small modular reactors, geothermal, and on-site solar-plus-storage. Microsoft's 2024 deal to restart Three Mile Island is the highest-profile version. SMRs are the most speculative, but the physics favors nuclear for 24/7 high-density loads. Grid interconnection queues are 3 to 7 years in most US markets, which is longer than the useful life of a GPU generation.
Algorithmic efficiency. This is the one the industry underweights. Quantization, distillation, speculative decoding, and MoE routing can cut inference energy by 5 to 10x for the same quality. A 4-bit quantized 70B model running on the right hardware can match a 16-bit version on many tasks at a fraction of the power. The cheapest watt is the one you don't draw. Notice the pattern. Every alternative is a tradeoff between capital cost, operational complexity, and geographic flexibility. There is no free lunch. There is only a different bill.

The Physics Limit Nobody Wants to Say Out Loud
Here's the part that gets buried in every vendor whitepaper.
The second law of thermodynamics says you cannot reject heat without doing work. The higher the ambient temperature, the harder it gets. The denser the rack, the more work per unit volume. There's no technology that breaks this.
What that means practically: the AI industry's thermal problem gets worse, not better, as models scale. A 10x increase in compute at the same efficiency is a 10x increase in heat that has to go somewhere. Efficiency improvements buy you time. They don't buy you a different equation.
The only paths out are:
Stop scaling compute (politically and commercially unlikely)

Move to places with abundant cold and clean power (Iceland, Norway, Quebec, and a handful of others, and they're filling up)

Build generation on-site (SMRs, geothermal, which take a decade to deploy)

Make the compute itself radically more efficient (quantization, distillation, better architectures, which helps but doesn't eliminate the problem)

If you're betting on AI scaling, you're implicitly betting on one of those four. Most people building in this space have not thought about which one.
What To Actually Do
Three moves, concrete enough to act on.

Add thermal and water metrics to your infrastructure monitoring. If you're running inference or training at any meaningful scale, instrument for:

# Minimum viable sustainability telemetry for an AI workload
metrics = {
    "gpu_power_w": gpu_power_draw(),           # per-GPU wall power
    "facility_pue": total_facility_power() / it_power(),
    "wue_l_per_kwh": water_liters() / energy_kwh(),
    "grid_carbon_g_per_kwh": grid_intensity(region),
    "marginal_emissions_g": marginal_grid_emissions(region, load_mw),
    "tokens_per_joule": tokens_generated() / energy_joules(),
}

If you can't fill in every field, you don't know your footprint. Start there.

Treat tokens-per-joule as a first-class metric. Most teams optimize for latency and cost per million tokens. Add energy per token to the dashboard. A 4-bit quantized model with speculative decoding can cut energy per token by 3 to 8x with minimal quality loss on most tasks. That's not a niche optimization. It's the single highest-leverage efficiency move available today.
Site for physics, not for tax breaks. If you're choosing where to run workloads, weight cold climate, low-carbon grid, and water availability above tax incentives. The next decade of data center buildout will be constrained by interconnection queues and water rights, not by land cost.

The Mental Model

Here's the lens I want you to keep.
AI's environmental cost is not a side effect. It's a physical throughput constraint on the entire industry, and it's the one constraint that no amount of capital can engineer away in the short term. Compute scales with money. Water and heat rejection scale with physics. The mismatch is the crisis.
The interesting question is not whether AI can be sustainable. It's whether the industry will treat thermal management as a core engineering discipline, the way it treats model architecture and chip design, before the constraints force the issue. The companies that get this right will have a structural advantage for the next decade. The ones that don't will be buying water rights in a drought.
What's your read? If you've worked on AI infrastructure, what's the real bottleneck in your experience: power, water, chips, or something else entirely? Drop it in the comments. I'm especially curious whether the water story is as underdiscussed in practice as it looks from the outside.

The Cooling Crisis: Why AI's Water and Energy Appetite Is Unsustainable—and What Might Replace It

VelocityAI — Tue, 13 Oct 2026 15:35:59 +0000

A hyperscale AI training cluster of 100,000 H100s pulls roughly 70 to 100 MW continuous. That's a small city's worth of power, running 24/7 for months during training.

Carbon intensity of the grid the facility sits on

Embedded carbon in the GPUs, which is enormous and amortized over 3 to 5 years

The marginal load the facility adds to a strained grid, which is often fossil-fuel peaker plants

The Real Alternatives, Ranked by Physics (Not Marketing)
Let's talk about what actually works, because the alternatives are not equal.

Liquid immersion cooling. Direct-to-chip and full immersion cooling replace air with dielectric fluid or water-glycol loops. Heat rejection capacity per rack jumps from 20 to 30 kW to 100 to 200 kW. Microsoft's Project Natick demonstrated sealed underwater data centers with a PUE around 1.07 over two years. Immersion is real, it's shipping, and it's the most likely near-term replacement for high-density AI racks. The tradeoff: retrofit cost, fluid handling, and the fact that most data centers weren't built for it.
Two-phase and phase-change cooling. Boiling a dielectric fluid at the chip level carries away far more heat per unit volume than single-phase liquid. Startups like CoolIT, ZutaCore, and Accelsius are shipping this. It's more efficient than single-phase, but it's harder to maintain and the fluids are expensive.
Free cooling and climate siting. If you can reject heat to ambient air for most of the year, you don't need evaporative water at all. This is why data centers are moving to Iceland, Norway, Sweden, and parts of Canada. Free cooling is the cheapest option when the climate allows it, and it's why the "build in the desert" model is going to die.
Heat reuse. Rejecting heat into district heating networks, greenhouses, or industrial processes. Stockholm's data centers already do this. It's the highest-leverage move because it turns a waste stream into a product. The constraint is geography: you need a customer for the heat, and most data centers aren't near one.
Behind-the-meter generation. Small modular reactors, geothermal, and on-site solar-plus-storage. Microsoft's 2024 deal to restart Three Mile Island is the highest-profile version. SMRs are the most speculative, but the physics favors nuclear for 24/7 high-density loads. Grid interconnection queues are 3 to 7 years in most US markets, which is longer than the useful life of a GPU generation.
Algorithmic efficiency. This is the one the industry underweights. Quantization, distillation, speculative decoding, and MoE routing can cut inference energy by 5 to 10x for the same quality. A 4-bit quantized 70B model running on the right hardware can match a 16-bit version on many tasks at a fraction of the power. The cheapest watt is the one you don't draw. Notice the pattern. Every alternative is a tradeoff between capital cost, operational complexity, and geographic flexibility. There is no free lunch. There is only a different bill.

Move to places with abundant cold and clean power (Iceland, Norway, Quebec, and a handful of others, and they're filling up)

Build generation on-site (SMRs, geothermal, which take a decade to deploy)

Make the compute itself radically more efficient (quantization, distillation, better architectures, which helps but doesn't eliminate the problem)

Add thermal and water metrics to your infrastructure monitoring. If you're running inference or training at any meaningful scale, instrument for:

# Minimum viable sustainability telemetry for an AI workload
metrics = {
    "gpu_power_w": gpu_power_draw(),           # per-GPU wall power
    "facility_pue": total_facility_power() / it_power(),
    "wue_l_per_kwh": water_liters() / energy_kwh(),
    "grid_carbon_g_per_kwh": grid_intensity(region),
    "marginal_emissions_g": marginal_grid_emissions(region, load_mw),
    "tokens_per_joule": tokens_generated() / energy_joules(),
}

If you can't fill in every field, you don't know your footprint. Start there.

Treat tokens-per-joule as a first-class metric. Most teams optimize for latency and cost per million tokens. Add energy per token to the dashboard. A 4-bit quantized model with speculative decoding can cut energy per token by 3 to 8x with minimal quality loss on most tasks. That's not a niche optimization. It's the single highest-leverage efficiency move available today.
Site for physics, not for tax breaks. If you're choosing where to run workloads, weight cold climate, low-carbon grid, and water availability above tax incentives. The next decade of data center buildout will be constrained by interconnection queues and water rights, not by land cost.

The Mental Model

The Longevity Hypothesis: Will AI Extend Human Lifespan by Decades, and What Would That Mean?

VelocityAI — Sun, 11 Oct 2026 10:14:03 +0000

Aubrey de Grey has been saying for twenty years that the first person to live to 1,000 is already alive. Most people roll their eyes. I used to. Then I started looking at what actually changed in the last five years of drug discovery, and the eye-roll got harder to sustain. Not because de Grey is right. Because the machinery he was waiting for has started to show up.

Here's the claim I want to test in this piece: AI will not cure aging. But it may compress the timeline of longevity research so aggressively that the social and economic questions we've been deferring for decades arrive before we've built the institutions to answer them.

That's a different argument than "AI will make us immortal." It's also a more useful one.

Let's walk through what's actually happening, where the hype exceeds the evidence, and one sacred cow in the AI-for-biology narrative that needs to be led to slaughter.

What AI Is Actually Doing in Drug Discovery (Not the Pitch Deck Version)
The press release version goes like this: AI designs a molecule, the molecule works, aging is solved. The reality is messier and more interesting.

What's actually happening:

Target identification. Models like AlphaFold 2 and its successors have compressed the protein structure prediction problem from months of lab work to minutes of compute. AlphaFold 3 extended this to protein-ligand and protein-nucleic acid complexes. That's not a cure. It's a 10x speedup on the first step of a 15-step pipeline.

Hit discovery. Companies like Recursion, Insilico, and Exscientia run closed-loop systems: generate candidates, test them in wet labs, feed results back into the model, iterate. Insilico's INS018_055, a drug for idiopathic pulmonary fibrosis, went from target to Phase II in roughly 30 months. The industry average is 4 to 6 years.

Repurposing. Models like those from BenevolentAI and Healx scan existing approved compounds for new indications. This is where AI has the strongest near-term case, because it skips the "is it safe in humans" question entirely.

Clinical trial design. AI selects patient cohorts, predicts dropout, and optimizes endpoints. This is unglamorous and saves years. A 2023 analysis of trial data suggested AI-driven cohort selection could reduce late-stage failure rates by 15 to 20 percentage points in oncology.

Notice the pattern. AI isn't curing anything. It's compressing the clock at every step. That compression is the whole story, and it's enough to matter.

But here's the part the longevity crowd skips: compressing drug discovery doesn't touch the biology of aging. It just gets us to the same wall faster. The wall is that we still don't have a validated therapeutic target for aging itself. We have hallmarks, pathways, and correlations. We don't have a target we can hit with a molecule and reliably extend human lifespan.

That's the actual bottleneck. It's not compute. It's biology.

The Sacred Cow: "AI Will Solve Aging Because It Solved Protein Folding"
This is the belief I want to dismantle, and it's held by a surprising number of otherwise serious people.

The logic goes: AlphaFold was a hard problem, AI solved it, therefore AI can solve aging. The error is treating "hard" as a single category.

Protein folding is a prediction problem. The output is a structure. The ground truth is a physical measurement. You can validate it in a lab in an afternoon. The feedback loop is tight, the data is abundant, and the problem is well-posed.

Aging is not a prediction problem. It's a causal systems problem. The output is a change in biological time across decades. The ground truth takes 30 years to measure. The feedback loop is measured in human lifetimes. The data is sparse, noisy, confounded by lifestyle, environment, and genetics, and the causal graph is so tangled that we're still arguing about whether senescence is a cause or a consequence.

You cannot gradient-descend your way through a problem whose loss function takes three decades to evaluate.

This is why almost every "AI cured aging in mice" story dies at the translation gap. Mice are not small humans. Mouse lifespan studies run 2 to 3 years. Human lifespan studies run 60 to 80. The feedback loop is 30x longer, and the biology is 30x more complex. AI doesn't change that math. It just makes the mouse studies faster.

The honest version: AI is compressing the preclinical timeline dramatically and the clinical timeline marginally. The preclinical timeline is maybe 10% of the total cost of bringing a longevity drug to market. The clinical timeline is 90%. And that 90% is bottlenecked by human biology, regulatory design, and the fact that you cannot ethically run a 40-year placebo-controlled trial on healthy people.

That's the wall. It's not compute.

What Would Decades Actually Look Like?
Let me take the strongest steelman seriously, because the social implications are the interesting part.

Suppose AI compression is real and durable. Suppose we get a validated longevity therapeutic in the next 15 years, and it adds 10 healthy years. Not immortality. A decade. What breaks?

The actuarial tables break first.

Pension systems, life insurance, annuities, and social security are all priced on mortality curves. If the tail of the distribution extends by 10 years, the math doesn't stretch. It collapses. A defined-benefit pension fund with a 30-year horizon is already fragile. With a 40-year horizon, most of them are insolvent.

The labor market inverts.

If people live to 110 and work to 90, you get a workforce with six generations active at once. Promotion timelines stretch. Entry-level roles get scarcer. The "OK boomer" dynamic becomes a structural feature of the economy, not a generational joke. And the compounding effect of wealth concentration accelerates, because capital with a 60-year horizon behaves differently than capital with a 30-year horizon.

The regulatory state isn't built for it.

Longevity therapeutics would be approved on the basis of biomarkers, not outcomes. Nobody will run a 40-year trial to prove you lived longer. So the FDA (and EMA, and PMDA) would have to accept surrogate endpoints, which is exactly the thing they've historically refused to do for anything but the most lethal diseases. That's a real regulatory fight, and it will delay access by a decade even after the science is settled.

The inequality story gets worse, not better.

The first generation of longevity therapeutics will be expensive. That means the people who get them will be the people who already have the most. A world where the wealthy live to 110 and the poor live to 75 is not a longevity utopia. It's a two-tier species. And the political legitimacy of that arrangement is not obvious.

The contrarian framing: longevity is a distribution problem before it's a biology problem. The biology is the exciting part, but the distribution is the part that determines whether it's good.

Where AI Actually Helps Beyond Drug Discovery
Here's the part I think is underrated.

Personalized medicine, driven by AI, is already extending healthy lifespan in narrow but real ways. Not by curing aging, but by preventing the top causes of death with better precision.

Cardiovascular risk prediction. Polygenic risk scores combined with imaging, labs, and wearable data now identify people at elevated risk of myocardial infarction years before symptoms. AI models outperform traditional risk calculators in multiple validation studies.

Cancer screening. AI-assisted mammography and low-dose CT reduce false negatives and catch disease earlier, which extends life even when it doesn't extend lifespan. That's a real win.

Diabetes and metabolic disease. Continuous glucose monitoring plus AI-driven insulin dosing and behavioral nudges materially reduces complications. GLP-1s are the pharmacological story of the decade, and AI is the reason they got to market faster.

Geriatric monitoring. Fall detection, medication adherence, early infection detection. Unglamorous, effective, and it keeps people out of hospitals.

Add these up and you get maybe 3 to 5 healthy years for people with access to good care. That's not decades. It's real.

The longevity hypothesis, in its strongest form, is really the compounding of these marginal wins across a population, plus a step-change from a genuine aging therapeutic. The step-change is speculative. The marginal wins are already happening.

The Mental Model: Compounding vs. Breakthrough
Here's the lens I'd ask you to hold.

There are two ways AI extends lifespan:

Compression. Making the existing pipeline faster, cheaper, and more precise. This is happening now, and it's worth years, not decades.

Breakthrough. Finding a therapeutic target for aging itself, and validating it in humans. This is speculative, bottlenecked by biology and regulation, and probably 20 to 40 years away, if it happens.

The mistake most people make is conflating them. They hear "AI is accelerating longevity research" and imagine a breakthrough. What's actually happening is compression. Compression is real, valuable, and much slower than the discourse suggests.

If you're a builder or researcher in this space, the implication is direct: the highest-leverage work right now is not in chasing the aging breakthrough. It's in the unglamorous infrastructure that turns biological data into usable signal. Clean longitudinal datasets. Federated learning pipelines. Biomarker validation. Regulatory-grade audit trails. That's where the compounding happens, and it's where the field is chronically underbuilt.

What To Actually Do
Three moves, concrete enough to start on Monday.

Follow the infrastructure, not the headlines. When you see an "AI cures aging" story, ask what step of the pipeline it's actually addressing. If it's preclinical, the timeline to human benefit is 10 to 15 years minimum. Adjust your expectations accordingly.
Watch the regulatory endpoint debate. The FDA's stance on surrogate endpoints for longevity therapeutics is the single most important policy variable in this space. If that shifts, the timeline compresses by a decade. If it doesn't, no amount of AI compute matters.
Build for the distribution problem, not just the science. The hardest questions in longevity are not "can we extend life" but "who gets it, who pays for it, and what happens to the people who don't." If you're building in this space, that's the part where you have the most leverage to shape outcomes, and the part most teams ignore.

If you want a single sentence to carry away: AI is making longevity research faster, not shorter, and the bottleneck was never compute. It was biology, regulation, and the fact that you can't run a 40-year experiment on people who are still alive.

The interesting question is not whether AI extends lifespan. It's whether we build the institutions to distribute the gains before the first effective therapy arrives. That window is closing, and most of us are not paying attention.

What's your read? If a longevity therapeutic arrived tomorrow and cost $50,000 a year, who should get it first, and who decides? That's the question that determines whether this is a triumph or a disaster. Drop it in the comments.

Medical Data as Commodity: Why Your Health Records Are the Most Valuable Training Data

VelocityAI — Sat, 10 Oct 2026 09:56:21 +0000

In 2021, a company you've probably never heard of quietly acquired the de-identified medical records of roughly 50 million Americans. The price was reported at around $1 billion. The records included diagnoses, prescriptions, lab results, and visit histories, stripped of names and Social Security numbers. The sellers were hospitals and health systems that had collected this data as a byproduct of care. The buyers were building products nobody had consented to be part of.

That's not a scandal. It's a business model. And it's the most important thing happening in medical AI that almost nobody is talking about.

We keep debating whether AI will replace doctors or whether models will hallucinate a dosage. Meanwhile, the actual ground truth of the entire medical AI industry is being extracted, packaged, and sold, one EHR at a time. If you want to understand where medical AI is going, stop reading model cards. Start reading data licensing agreements.

What follows is a teardown of how this market actually works, why your health record is worth more than your genome, and one contrarian claim that will make most AI builders uncomfortable. You'll walk away with a mental model you can apply the next time someone says "we train on de-identified clinical data."

Why Health Data Is Worth More Than Anything Else You Produce
Let's start with the economics, because the ethics only make sense once you understand the incentives.

Your social media posts are worth fractions of a cent. Your browsing history, maybe a few dollars a year. Your genome, in raw form, has been commoditized to the point where sequencing companies will give you the test for free to get the data. But your longitudinal medical record, the years of diagnoses, prescriptions, lab trends, imaging notes, and outcomes, is genuinely rare.

Here's why:

It's longitudinal. A snapshot of your health is nearly worthless. A decade-long record with outcomes is a goldmine, because it lets models learn what happens after a diagnosis, not just what the diagnosis was.

It's labeled. Unlike scraped web text, clinical records come with structured codes, standard vocabularies, and physician annotations. That's the difference between an unsupervised pile of text and a supervised training set.

It's scarce. The entire open web is a firehose. Clean, longitudinal, outcome-linked clinical data is a trickle. Scarcity drives price.

It's multimodal. Imaging, labs, notes, genomics, vitals. Most training data is single-modality. Clinical records are naturally multi-modal, which is exactly what frontier medical models need.

The result is a market where de-identified patient records trade in the hundreds of millions to low billions, and where the buyers are not just hospitals but insurers, pharma companies, and increasingly, AI labs that need clinical data to fine-tune medical models.

The Consent Illusion
Here's the part that should bother you, even if you're a pragmatist.

Most of this data is collected under the banner of "de-identification," governed by HIPAA in the US and GDPR in Europe. The pitch is simple: strip the identifiers, and the data is no longer personal. Problem solved.

Except de-identification is not the same as anonymization. A 2019 study in Nature Communications showed that re-identification of de-identified health data is often trivially easy with auxiliary datasets. A 2022 paper demonstrated that a model trained on "de-identified" records could recover patient names from clinical notes at rates that should concern anyone who has ever signed a HIPAA form.

And the consent that patients give when they enter a hospital is not consent to train models. It's consent to treatment. The two are legally distinct, ethically worlds apart, and practically conflated all the time.

Consider the actual mechanics:

You sign a Notice of Privacy Practices. It's 10-15 pages. It says your data may be used for "treatment, payment, and operations."

Somewhere in there, buried, is language about "research" and "business associates."

You don't read it. Nobody reads it. That's the point.

Your data is then de-identified and sold to a data broker, who sells it to a model developer, who uses it to train a system that may eventually be sold back to your hospital.

You were never asked. You were never told. And you were never compensated. The transaction happened in a language you weren't fluent in, on a timeline you didn't control.

The Sacred Cow: "De-Identified Data Is Ethically Safe"
I want to slaughter a sacred cow that the AI community has been grazing on for years: the belief that de-identified data is ethically equivalent to non-personal data.

This belief is load-bearing. It's the legal and moral foundation of an entire industry. And it's mostly wrong.

Here's why. De-identification removes direct identifiers. It does not remove distinguishability. A de-identified record with a rare diagnosis, a specific age, a ZIP code, and a procedure date is often unique to one person in a population. That uniqueness is not a bug; it's the feature that makes the data valuable for training. The very properties that make clinical data useful for models are the properties that make it re-identifiable.

The tech industry has spent a decade telling itself that if the name is gone, the person is gone. That's not true. A person is a distribution, not a field. Remove the name field, and the distribution remains. A model can learn your patterns without ever knowing your name, and that's enough to make inferences about you, sell to you, or discriminate against you.

The ethical upshot is uncomfortable: de-identification is a legal shield, not a moral one. The industry relies on it not because it's right, but because it's defensible. And defensibility is not the same thing as consent.

Where the Value Actually Flows (Spoiler: Not to You)
Follow the money for a moment.

The patient produces the data as a byproduct of care. Gets no compensation, no transparency, no opt-in.

The hospital collects the data and sells it to a data broker for a lump sum or a per-record fee. The revenue is often small relative to the hospital's budget, which is why the sale happens quietly.

The data broker aggregates and cleans the data, then licenses it to multiple buyers. This is the layer where most of the margin lives.

The pharma company or AI lab uses the data to train models, validate drugs, or develop diagnostics. This is where the value compounds.

The hospital may eventually buy back a model trained on its own patients' data, at a price it can't negotiate because it's locked into a vendor.

The patient is the source. The patient is the subject. The patient is the last person in the chain to see any benefit.

There's a word for this in other industries: extraction. The tech community has spent years critiquing "data extraction" from users by social media platforms. It's time to apply the same lens to medicine.

What Good Looks Like (and Why It's Rare)
I don't want to leave you with nothing but critique. There are models that work, and they're worth studying.

Synthetic data. GANs and diffusion models can generate synthetic patient records that preserve statistical properties without exposing any real individual. Early results in oncology and cardiology are promising, though the fidelity gap is real and often undersold.

Federated learning. Training across hospitals without moving data. Google's work with hospital networks on mammography is the canonical example. It's slower, more expensive, and harder to deploy, which is exactly why it's rare.

Patient consent frameworks. Some cohorts, like UK Biobank and All of Us, build explicit, revocable consent into the design. The tradeoff is scale: these cohorts are orders of magnitude smaller than the aggregated data broker market.

Data trusts and cooperatives. Models where patients hold governance rights and share in revenue. Early pilots exist. None have reached the scale of the commercial market.

Notice the pattern. The ethical approaches are slower, smaller, and less profitable. That's not a coincidence. It's the entire reason the commercial market exists in its current form.

What To Actually Do About It
If you're a builder working in medical AI, you have more leverage than you think. Three concrete moves.

Ask for provenance, not just de-identification. When you acquire or license clinical data, ask where it came from, how consent was obtained, and whether patients have any recourse. If the vendor can't answer, you're building on sand. Document the answer in your model card.
Instrument for re-identification risk. Before you train, run a re-identification audit. Use k-anonymity metrics, membership inference tests, and auxiliary dataset attacks. If your "de-identified" dataset fails these tests, it's not de-identified. It's just unidentified until someone tries.
Prefer federated and synthetic pipelines where they fit. They're harder and slower. They're also the only defensible long-term path if regulation tightens. Build the muscle now, before you're forced to.

If you're a patient, here's the harder truth: you have almost no leverage in the current system. The best you can do is read the Notice of Privacy Practices at your next visit, ask whether your data is shared with third parties, and opt out where allowed. It won't stop the market. But it will teach you how the market works, and that knowledge compounds.

The Mental Model
Here's the lens I want you to keep.

Medical data is not a resource. It's a relationship. It's a record of a person's body, their fears, their diagnoses, and their worst days, compressed into structured fields and sold to the highest bidder. The industry treats it as a commodity because that's the only way the economics work. But the economics are a choice, not a law of nature.

Every time you build a model on clinical data, you are borrowing someone's worst day to build something better for the next person. That's a legitimate thing to do. It's also a debt. The question is not whether we'll use medical data to train models. We already are. The question is whether the people who produced that data will ever be treated as parties to the transaction rather than inputs to it.

The market has an answer. It's not a good one.

What's your read on this? If you've worked with clinical data, how did you handle consent and provenance? If you haven't, would you want to know if your records were sold? Drop it in the comments. I'm genuinely curious how the builders in this space are thinking about it.