Concept</th>	Why It Can't Be Skipped</th></tr></thead>
Commits</td>	The fundamental unit — same in both</td></tr>
Remotes</td>	GitHub is a remote, this doesn't go away</td></tr>
`fetch</code> / push</code></td>`	Still how you sync with the forge</td></tr>
Bookmarks vs. Branches</td>	PRs on GitHub are branch-based; JJ's bookmarks map onto this but the translation isn't obvious and confuses many people new to JJ</td></tr> </tbody></table> The bookmarks-to-branches translation is the hardest part. When a student wants to open a pull request on GitHub, they need to understand that their JJ bookmark becomes a Git branch becomes a PR. That's three layers of abstraction for someone who just wants to submit their homework. Also without the common `tug</code> alias, remembering to move your bookmarks and the exact way to do that can be tedious and easy to get incorrect, potentially poluting the upstream repo</p>` What a JJ-First Curriculum Might Look Like</h2> Level 0 — Just track changes locally</em>: jj init</code>, jj status</code>, jj describe</code>, jj log</code>. No remotes, no branches, no pushing. Get comfortable with the idea that every save is being tracked and you can always go back.</p> Level 1 — Work with a remote</em>: jj git clone</code>, jj git fetch</code>, jj git push</code>. Introduce the concept of a remote as a mirror. Still no branches.</p> Level 2 — Collaborate</em>: Bookmarks, how they map to Git branches, opening a PR. This is where the Git-forge translation layer gets introduced explicitly — "the rest of the world uses Git, here's how JJ talks to it."</p> Level 3 — Power tools</em>: Revsets, jj rebase</code>, jj split</code>, jj absorb</code>, jj op undo</code>. The stuff that makes JJ genuinely better than Git for anyone doing non-trivial history management.</p> The Jujutsu for Everyone</a> guide is structured similarly and is worth reading if you're thinking about this problem — they're actively building out exactly this kind of zero-prior-experience curriculum.</p> Open Questions</h2> I don't have a clean answer yet. JJ's core model should be simpler than git if you didnt need to think about git and I believe it is more forgiving for new developers. But the forge ecosystem means you cannot fully escape Git concepts. The question is whether you're better off teaching Git as the foundation and JJ as an upgrade, or teaching JJ as the foundation and Git as a compatibility layer you'll sometimes need to think about.</p> My instinct is the latter. The mental model of "your working copy is always a commit, and you can always undo" is a healthier foundation than "here are four zones and eight commands."</p> We Need Societal Scaling Laws Unknown — Sat, 07 Mar 2026 00:00:00 +0000 In AI research, scaling laws are gospel. Put in $X$ more compute, get $Y$ improvement in capability. The Chinchilla paper, the GPT-4 technical report, every major lab's internal planning documents—they all revolve around trying to develop these predictable relationships between resources and outcomes. Scaling laws are what is used to justify billion-dollar investments. They're why datacenters are being built at unprecedented scale.</p> </p> We have scaling laws for the returns on investment in terms of capability yet we do not have similar normative models for how we believe widespread application of these technologies will change society. We are not running instructive small scale experiments on what a society with LLMs deeply woven in will look like.</p> To be clear from the outset: this is not an argument to slow down. It's that capability research has billion-dollar investment guided by predictive curves. Societal preparation has none of that. The argument here is for foresight, not restraint.</p> LLMs at scale could make institutions more contextually sensitive than they have ever been: capable of seeing people as individuals rather than averages, catching bad-faith exploitation that formal rules can never reach, delivering the judgment that scarcity of cognition forced us to compress into crude metrics. Or it could make them more totalizing and less escapable than anything that came before. Perfect enforcement, crystallized bias, Foucault's Panopticon</a> fully realized, autonomy eroded not by malice but by optimization. LLMs could allow you to be seen as an individual. It also could mean you can never not be seen. Both outcomes are technically possible. This is with LLMs as they are now, imperfect inverse mechanical turks</a> masquerading as oracles. Layers of probabilistic modeling stacked on top of each other. Superintelligence is not required for society to change drastically around this technology. This essay is not arguing that we are saved or we are doomed. It's arguing that we are deploying LLMs into institutions without the instruments to know which trajectory we're actually on.</p> Society is Built on Scarcity</h2> Before the industrial revolution, physical labor was the scarce resource that organized everything—where people lived, how families worked, what children did, how authority was justified. The steam engine dissolved that scarcity, and the consequences weren't mainly economic: it forced into existence the modern city, compulsory education, the 8-hour workday, labor law, the welfare state. Not automatically—through generations of conflict and experiment. The disruption wasn't primarily about wages; it was about what kind of life was possible and what society was obligated to protect.</p> LLMs threaten to do the same to cognitive labor. Every institution we have is downstream of the assumption that cognitive work is scarce and therefore has to be rationed. Tax authorities audit a sample of returns because they can't audit all of them. Food safety inspectors sample products. Financial regulators examine a fraction of transactions. Courts process a fraction of disputes. The entire architecture of governance, markets, law, and expertise is built around one constraint: you cannot check everything, so you check enough to maintain trust. LLMs have the potential to eliminate that constraint.</p> The industry's boldest response is Universal Basic Income</a>: a stipend. UBI is a pure economic answer to what is not just an economic problem. It asks "how do people afford things" and ignores every harder question underneath: what do people do</em>? What gives their lives structure? How do communities cohere? These are moral questions, not monetary ones—the same questions the industrial revolution forced into the open over decades of conflict, which we seem determined to defer again. If you can audit every tax return, what does the IRS look like? If cognitive expertise is no longer scarce, what do the institutions built around rationing it look like? Those aren't economic questions. They're questions about what governance is for</em>.</p> More broadly, ordinary life has always depended on the practical limits of what can be known, tracked, or enforced. Society isn't just built around what rules say; it's built around what rules can reach. A family builds a deck without pulling permits because the permit process is expensive and their neighborhood isn't regularly inspected. A landlord rents a basement bedroom without an egress window</a> in a city with a severe housing shortage because inspectors only respond to complaints, and nobody complains because the tenant needs the housing. Someone moves to a new city and quietly leaves a bad chapter behind them, because records didn't follow people the way they do now. A person asks a friend who happens to be a doctor for informal advice they couldn't afford to pay for officially. A small business owner asks a favor from someone they've known for years rather than going through a formal procurement process that would disadvantage them. None of these are heroic. They're just how life works when the cost of full compliance is high and the probability of being checked is low.</p> The same logic applies beyond individual choices. Communities develop informal economies around what official systems can't or won't serve: the neighbor who fixes cars, the informal childcare network, the loans between members of a family that doesn't involve a bank. Privacy itself has historically been less a right than a byproduct of practical obscurity: your medical history, your spending habits, your location throughout the day weren't tracked not because tracking was forbidden but because it was expensive. The gaps in visibility weren't accidental; they were structural, and people built lives inside them.</p> The intuition is that this is all a failure to be corrected. That if we could just enforce everything uniformly, things would be fairer and better. Sometimes that's true: selective enforcement often falls hardest on people with the least power to push back. But the gaps also do work that's hard to see until it's gone. They're how rules that don't quite fit get quietly negotiated. How communities absorb people who can't meet formal requirements but have nowhere else to go. How ordinary life remains livable under systems that were designed for an average case that doesn't describe everyone. LLMs don't just change enforcement; they change the underlying structure of what can be known and tracked. The question isn't only what laws will be applied more uniformly. It's what kind of life is possible when practical obscurity disappears. Discord's 2026 age verification rollout</a> is a mundane but clarifying example: a platform used by hundreds of millions of people decided that to access its full features, users would need to submit to a facial scan or upload a government ID to a third-party vendor. This happened six months after a breach exposed 70,000 users' government IDs and selfies</a> from a previous verification vendor. The logic is not malicious. The platform has genuine obligations around age-gated content. But the infrastructure being built (verified identity required for full platform participation) is the same infrastructure that makes practical obscurity structurally impossible.</p> What LLMs offer looks like comprehensive uniform governance but it's a black box that trades acknowledged incompleteness for hidden inconsistency. Training data biases, RL artifacts, distributional shift: these produce failures that aren't random and visible like under-sampling, but systematic and opaque, baked into weights no one can fully read. You've swapped a system that knew what it was missing for one that doesn't know what it's getting wrong. There is no avoiding the LLM audit when the LLM audit costs a few hundred dollars of compute. There is a subtler change here: a move from retrospective to live accountability. Every major institution of accountability we have built is fundamentally backward-looking. Courts reconstruct what happened. Regulators investigate past conduct. Auditors review historical records. Trials are an elaborate technology for producing a credible account of the past. The entire architecture of law assumes that what institutions can do is hold people accountable for what they have done: after the fact, episodically, at the cost of enormous effort. That retrospective character is a feature as much as a limitation: it means people live their lives forward, without continuous institutional observation, and face judgment only when someone decides to look.</p> LLMs at scale changes that architecture. Not to the Minority Report style predicting of future crimes, but to something potentially as pervasive: live observation of the present. When every transaction, communication, and movement is processable in real time, institutions don't have to reconstruct what happened; they can watch it happening. This is the shift from episodic accountability to continuous monitoring. It has versions in both directions. The contextualizing version: harm gets caught as it compounds, not years later after a pattern has solidified beyond remedy. The totalizing version: people no longer have the slack of practical obscurity (the room to fail, recover, and move on that an episodic accountability architecture quietly provides). A juvenile record that a judge might have sealed gets embedded in a risk score. A period of financial difficulty that a loan officer might have contextualized becomes a permanent feature of a profile. The difference between those two versions isn't the technology. It's whether the governance layer is designed with the retrospective virtues in mind: that some forgetting is a feature, not a bug.</p> These aren't questions about who gets paid. They're questions about what institutions are for</em> once the scarcity they were built to manage no longer exists. Jeremy Rifkin anticipated part of this in The Zero Marginal Cost Society</em></a> (2014), arguing that near-zero marginal cost production would erode capitalism and give rise to a collaborative commons. His focus was economic: markets, ownership, profit. The institutional argument is deeper: it's not just that capitalism struggles when things become free, it's that governance itself</em> was designed for a world where you couldn't check everything. James C. Scott's Seeing Like a State</em></a> (1998) documents this exhaustively: states make society "legible" through simplification (standardized names, censuses, uniform measurement) because "no administrative system is capable of representing any existing social community except through a heroic and greatly schematized process of abstraction and simplification." Hayek made the point in The Use of Knowledge in Society</em></a> (1945): knowledge is irreducibly dispersed, and no central authority can ever aggregate enough of it to fully govern. Decentralized, spot-check institutions aren't a design failure; they're a rational response to the impossibility of complete information. C. Thi Nguyen's The Score</em></a> (2025) identifies the tension with decontextualization via quantification. Numbers travel, institutions are built around stripped metrics of society because this is the best we could do to run society in a uniform ("just") way. A credit score can be processed by a thousand different loan officers in a thousand different cities; a nuanced assessment of someone's full financial situation or repayment habits cannot. Metrics strip context so that judgment can scale; however, Nguyen documents what is left behind when this happens—all the nuance dropped, the consequences of centralizing standardized metrics in your life. The technology to change this now exists. Society necessarily changes in a world where the marginal cost of analysis approaches zero. Yet we are operating as if 20th-century institutions smoothly adopt 21st-century capability.</p> "Scalable contextual judgment" is a capability, not a value, and capabilities go in any direction. Replace the credit score with an AI that actually understands someone's financial situation: that could mean fairer lending, or it could mean lenders now have perfect information about every part of your life and no way to improve your credit score. The same dissolution of cognitive scarcity that makes individual judgment richer could make institutional reach total. Which one we build is not a technical question. It's a governance one.</p> Data As Law</h2> In 1999, Lawrence Lessig argued in Code and Other Laws of Cyberspace</em></a> that behavior online is regulated by four forces: law, norms, markets, and architecture. His warning was that code—the architecture of cyberspace—was becoming the most powerful of the four, and that unlike law, code has no appeals process. It just executes.</p> Law is fuzzy by design. It has context, interpretation, precedent, exceptions. A judge can decide that the letter of a statute doesn't apply to an unusual case. A jury can acquit on conscience. These aren't bugs—they're features, the accumulated wisdom that rigid rules applied without judgment produce injustice. Fuzziness is how law accommodates the infinite complexity of human situations.</p> Code is absolute. An if-statement doesn't care about context. A smart contract executes whether or not execution is fair. Bitcoin doesn't make exceptions. This is precisely what cypherpunks</a> found appealing: rules that couldn't be bent by the powerful, enforced by math rather than men. Code as a replacement for trust in institutions</a>.</p> The ideological throughline from Bitcoin to AI alignment is not accidental. Many of the same people, or at least the same type of people—rationalists</a>, effective altruists</a>, believers in formal systems over human judgment—migrated from crypto to AI safety carrying the same core intuition: that you can encode ethics into a system, that values can be specified precisely enough to be executed reliably. The dream is a Platonic one: a reasoning agent that receives principles and derives correct behavior from them the way a philosopher derives conclusions from premises. Write the right constitution, and the model applies it. The world's best virtue ethicist.</p> Anthropic's Constitutional AI</a> is the most legible attempt at this. They literally wrote a constitution for Claude, a list of principles drawn from documents like the UN Declaration of Human Rights, and trained the model to critique and revise its own outputs against those principles. The name is deliberate: here are the values, encoded in text, now reason from them.</p> The problem is the model isn't doing what the framing implies. A constitution binds a reasoning agent that interprets and applies its principles. What Constitutional AI actually produced is a statistical model fine-tuned to generate outputs consistent with how constitutionally-flavored reasoning appears in text. Those are different things. The model doesn't derive behavior from the constitution the way a judge derives rulings from precedent. It produces outputs that pattern-match to what applying-this-constitution looked like in training data. In distribution, that can look indistinguishable from principled reasoning. Out of distribution, at genuine edge cases, novel cultural contexts, situations the rater pool never encountered, there is no logical guarantee. This is what "prompt injection" is. Its an input that forces the model into a regime where the statistically consitent response violates the governance layer laied on top. The constitution didn't bind the model. It shaped the weights. That gap is where the failure modes live.</p> The Three Laws of Robotics</a> are the most famous fictional attempt at the same program, and the entire corpus of robot stories is a catalog of their failure modes. Not because the laws are badly written, but because the fuzziness they tried to eliminate keeps reasserting itself: every story finds a situation the laws didn't anticipate. Asimov demonstrates that you cannot specify human values precisely enough to execute them reliably, that a reasoning agent genuinely applying rigid principles will eventually encounter a case where the principles conflict or don't reach. LLMs aren't true reasoning agents encountering edge cases in the laws. They do not build conceptual abstractions and manipulate them according to rules in the same way humans might. They're statistical models producing outputs that looked like reasoning in training, which is a subtler and harder-to-diagnose failure mode.</p> The public debate about AI is structured around a question that turns out not to matter: is this thing actually reasoning, or just predicting tokens? The popular conception—the one animating both techno-utopian and extinction-risk discourse—is of a mechanistic human: an agent with goals, values, something like intent. LLMs are not that. But the societal consequences don't hinge on whether it is or not. A statistical parrot deployed at institutional scale, trained on whoever's data, shaped by whoever's rater pool, still makes decisions that govern people's lives.</p> This points to something Lessig's framework didn't anticipate: in a world of LLM-informed governance, data is law. The training corpus is the actual constitution. Whatever was overrepresented in the pretraining data, whatever the rater preferred during finetuning, whatever got filtered in or out—those are the binding documents. They were never written down, have no preamble, nobody voted on them, and you cannot look them up. Constitutional AI wrote a visible constitution on top of a data constitution that already existed and was already shaping every output. The written one is the legible governance layer. The real one is hundreds of billions of tokens of human text, with all its biases and distributional skews baked into weights no interpretability technique can fully read.</p> Data-as-law has different properties from both of Lessig's categories, with distinct failure modes. Code is deterministic and auditable: you can read the contract, find the bug. Law is fuzzy and has appeals: the written text can be challenged, the edge case can go to court. Data-as-law is statistical and opaque: the outputs appear contextual, but the context-sensitivity isn't deliberate like a judge's, it's distributional, a reflection of what the training data happened to contain. The biases aren't in a rule you can find and argue against. They're in the shape of the distribution, invisible until they produce an outcome someone bothered to measure.</p> The approach for encoding ethics varies across labs; the shape is always the same: someone decides what the values are, encodes them through whatever mechanism they've chosen, and deploys the result without the public deliberation or democratic mandate that would be required of any analogous human institution.</p> This is their best attempt at governing AI's societal trajectory, and it operates entirely from the model out, not from society in. It does not ask whether LLMs are pushing institutions toward the contextualizing attractor or the totalizing one. It asks only whether the model behaves. Those are not the same question. And when LLMs with the capability to apply contextual judgment at institutional scale get deployed, the question of whose context it's applying doesn't get answered by writing a better constitution. It gets answered by whoever controlled the training pipeline. The capability to scale judgment is value-neutral. What gets scaled is the data.</p> The Unintentional Regulator</h2> The tech industry operates in a perpetual race. Capture the market before someone else does. Ship the feature before it's commoditized. Train the model before your competitor. Move fast and break things—the motto that defined an era and never really went away, they just have a different slogan</a> now. This isn't a moral failing of individuals; it's game theory. If you don't capture the value, someone else will.</p> The most revealing case is Anthropic. They are, by their own account</a>, the lab most convinced that they might be building one of the most dangerous technologies in human history. They built an entire Responsible Scaling Policy</a> around the premise of not deploying models unless adequate safeguards exist. And then, under competitive pressure, they dropped the flagship pledge</a> that was supposedly the whole point of the company. They operate in a Hegelian</a> sense: the technology is inevitable, history has already decided, so the only meaningful choice is whether the people who take the risks seriously get there first. Existential concern about AI is now an argument for</em> building faster, not slower.</p> Ironically, despite tens of thousands of words in think pieces on the implications of AI and entire research fields devoted to alignment and safety, the most effective governor on AI development turned out to be TSMC's N3 process yield rates</a>. Not a law. Not a treaty. Not a democratically mandated pause. A semiconductor fabrication bottleneck and a lack of cheap electricity.</p> NVIDIA's Blackwell architecture shipped roughly 1.5 to 2 million units in 2025</a> not because anyone deliberated about whether society was ready, but because of the limitations of lithography throughput, DDR5 yields at Micron, how many generators you can buy. The most consequential "AI governance" decision of 2026 was made in a fab in Hsinchu and city council meetings about substation lead times. Physical reality is doing what policy couldn't.</p> That bottleneck is being engineered away on both sides of the geopolitical divide as aggressively as possible. The export controls that weaponize this bottleneck in order to slow China down are demonstrably not working</a>: DeepSeek built frontier-competitive models on restricted chips by programming around their bandwidth limitations at a lower level than CUDA</a>; the controls didn't slow them down, they forced an efficiency breakthrough. Huawei is planning to double Ascend AI chip output in 2026</a>. When those constraints loosen, we'll discover that we never actually built a governance system. We just got lucky that the supply chain was the bottleneck first. When compute costs drop by a factor of ten, and despite the end of Dennard scaling</a>, they likely will, what required a hyperscaler becomes feasible for a startup, then a hobbyist.</p> Crucially, supply chain physics don't resolve the tension; they only control the speed at which we approach it. Whether LLMs in institutions converge on the contextualizing attractor or the totalizing one is not a question wafer yields can answer.</p> The Laziness of Extinction Discourse</h2> The community that should be asking 'which future are we building?' is asking a different question entirely. The popular public discussions about AI safety began with a focus on extinction risk: will superintelligent AI decide to eliminate humanity? Will we lose control of systems more capable than ourselves?</p> The focus on extinction is a failure mode disguised as rigor. It has the aesthetic of serious thinking (philosophical depth, civilizational stakes) while actually functioning as an escape hatch from the harder, messier, more tractable questions about the society we're building right now. Extinction is the one scenario where you don't have to do the institutional work, because if it happens there are no institutions left to fix. It's the most intellectually convenient possible framing.</p> Extinction is binary. We survive or we don't. It lets you skip the infinite gradations between "everything is fine" and "everyone is dead": where the actual future will lie. A world where AI works but democracy doesn't isn't an extinction scenario. Neither is a world of abundance and spiritual emptiness, where we solved AGI but not meaning. Neither is a world where the people building these systems made choices about whose values to encode without any democratic mandate, and we only noticed after the fact. These aren't edge cases. They're the likeliest futures. And extinction discourse has nothing useful to say about any of them.</p> There's also a practical problem: it's been a decade of serious public investment in x-risk as a framing, and the main thing it has produced is a community with a strong aesthetic identity and a negligible effect on actual deployment decisions. The labs that take existential risk most seriously, Anthropic, have sped up not slowed down. The framing has not generated the institutional responses or the governance infrastructure that would constitute taking it seriously. It has generated a lot of essays, a lot of funding for capability research disguised as safety research, and a career path for people who want to think about AI without thinking about any specific deployment or variant of "AI".</p> The deep questions about an AI-native society go unasked because they're hard and ultimately human-centered, not technological. Consider: the personal computer has existed for roughly 45 years, the internet has been mainstream for 30, and we're still working out their second and third-order effects: cybersecurity, mass data collection, algorithmically mediated media. The speculation was extensive at the time about what the cyber-future will hold and how we should manage cyberspace: Alvin Toffler's The Third Wave</em></a> (1980) anticipated the information society before the PC was widespread; Nicholas Negroponte's Being Digital</em></a> (1995) predicted digital convergence with remarkable accuracy; Howard Rheingold's The Virtual Community</em></a> (1993) mapped online social life before most people had experienced it; John Perry Barlow's "A Declaration of the Independence of Cyberspace"</a> (1996) staked out the libertarian governance vision that still shapes platform policy today. We did not lack for vision. Yet there were still deeply disturbing unforeseen outcomes. And we are even blinder now in the era of LLMs.</p> LLMs at institutional scale could move society toward institutions that are finally able to hold contextual complexity, or toward institutions that are more totalizing and less escapable than anything we have built before. Extinction discourse has nothing useful to say about which of those we're headed toward, because both of them involve humans surviving.</p> The Moral Machine 1</a></sup></h2> ^1</sup>The term borrows from MIT's Moral Machine</a> experiment (Awad et al., Nature</em>, 2018</a>), which crowdsourced human moral judgments about autonomous vehicle decisions across millions of participants in 233 countries. The experiment revealed substantial cross-cultural variation in moral intuitions (who to spare in a trolley-problem-style crash) and is a systematic attempt to empirically map the terrain of human moral judgment at scale. Its lesson was not that moral consensus exists and can be extracted; it was that moral intuitions are culturally contingent, contested, and resistant to simple aggregation. Any "moral machine" faces that problem first.</p> </div> Philip K. Dick's The Minority Report</a></em> is an illustration of what algorithmic governance looks like at institutional scale: a pre-crime system that arrests people for murders they haven't committed yet, based on probabilistic prediction. The horror isn't that it's wrong; the predictions are largely accurate. The horror is what it means to live in a society organized around algorithmic certainty rather than demonstrated action. Guilt becomes statistical. Justice becomes actuarial. The system is more accurate than human judgment and also more inhuman.</p> Take a real judge. Today, judicial discretion is a feature, not a bug. Sentencing guidelines exist, but judges can depart from them. A first-time offender with extenuating circumstances gets treated differently than a repeat one. A prosecutor can decline to pursue a case they consider unjust. The system is leaky by design, because the alternative (rigid rule application without context) produces outcomes so obviously wrong that every legal tradition across history has built in escape valves. The same tension applies when LLMs allocate jobs, admit students, set insurance rates, and decide parole, it could eliminate the nepotism and bias that currently shape these decisions. It could also calcify whatever assumptions were baked into training data, producing a more rigorous version of the same discrimination with less recourse. When a human rejects you, you can argue, appeal, find another human. When a system does, the decision feels categorical, produced by something that doesn't negotiate.</p> Less discriminatory hiring, more consistent sentencing: these could all be genuine improvements. But we would be arriving at them without the governance infrastructure to make them legitimate.</p> The problem Lessig identified used to cut both ways. Yes, encoding ethics into hard rules strips out the fuzziness that makes law humane. But fuzziness also has a cost: it was expensive to apply. Judgment takes time and expertise. You can't hire enough judges, regulators, or compliance officers to apply contextual reasoning at the scale that modern systems operate. So we defaulted to rules. Not because rules are better, but because rules are cheap.</p> That tradeoff is now shifting. We've had mechanisms for fuzzy judgment before. The jury is one. A group of peers, drawn from the community, asked not to apply a rule but to reach a verdict: to decide what a reasonable person would find. Lessig also points to deliberative polls</a>: randomly sampled citizens given balanced information and time to discuss, whose considered opinions turn out to look quite different from snap poll responses. Both are attempts to extract something like collective moral judgment without reducing it to a rule. Both are expensive, slow, and impossible to scale. A jury deliberates for days over a single case. A deliberative poll costs millions and takes months. They work, in their domain. But you can't run a jury on every financial transaction or a deliberative poll on every norm violation.</p> However, Nguyen's diagnosis points directly at what's new here. The gap Lessig identified (between what law says and what norms expect) exists precisely because enforcing norms requires context, and context doesn't travel. The moment you formalize "exploiting the spirit of the rule," clever actors find a new way to comply with the letter of your formalization while violating its spirit. Every attempt to encode a norm into a rule just moves the gap. The underlying problem is that norms are about the whole situation</em> (intent, pattern, effect, social meaning) and rules can only address specified features</em> of situations.</p> What LLMs offer is a system that might hold context without collapsing it into a score. Not a metric, but something closer to the judgment that generates metrics: pattern recognition across entire situations, including the parts that didn't fit neatly into the rule. Norms are implicit, contextual, and hard to articulate, but not to an LLM trained on billions of examples of human communication about what's fair and what isn't. How do you write a regulation that catches someone acting in bad faith? You might not need to write it. You might be able to describe the situation and ask.</p> It's also worth being clear that the system described in the rest of this section (a moral machine capable of reliable contextual norm enforcement) does not currently exist but is easy to imagine from current techniques and in no way requires general superintelligence to be convincing enough to deploy at scale.</p> </blockquote> Consider what this looks like in practice. High-frequency trading firms spend enormous resources finding strategies that are technically legal but structurally extractive; they don't buy and sell based on economic fundamentals, they arbitrage market microstructure in ways that impose costs on other participants without creating value. No specific rule is broken. Every individual transaction is legal. But the aggregate behavior is a kind of predation that most market participants would recognize as wrong if they could see it clearly. Rules-based regulation can't catch it because catching it requires reasoning about intent</em> and effect</em> across a pattern of behavior, not just checking whether individual transactions conform to specified constraints. The SEC issues guidance, adds new rules, watches the strategies mutate. It's an arms race that the regulators are structurally losing.</p> An LLM-based system asked to evaluate whether a trading strategy is fair</em> (not whether it's legal</em>) can reason about the question the way a thoughtful senior regulator would. Is this adding liquidity or extracting it? Is this participant providing a service to the market or imposing costs on it? Does the pattern, taken as a whole, serve or undermine the purpose markets are supposed to serve? These aren't algorithmic questions. They require the kind of contextual reasoning that formal systems have never been able to automate. Until now.</p> This opens something genuinely new: the possibility of identifying violations of norms rather than just laws. A "moral machine" that doesn't ask "did this actor violate rule 47(b)(2)?" but "did this actor behave in a way the community would recognize as wrong?" The difference is enormous. You could catch the tax lawyer who finds every loophole without breaking any rule. The company that technically complies with environmental regulations while deliberately undermining their intent. The landlord who never explicitly discriminates but systematically makes certain applicants' experience unpleasant enough to withdraw. These are norm violations that current law cannot reach: not because no one has tried to write the rules, but because the behavior is defined by context and intent that formal specification cannot capture.</p> This is not a simple good. Enforcing norms at scale means someone decides whose norms. The informal non-enforcement that allows communities to signal that a law is outdated, that makes space for civil disobedience, that permits the kind of friction where moral progress actually happens: that gets foreclosed too. A moral machine powerful enough to catch bad-faith exploitation is powerful enough to enforce consensus morality uniformly, without appeal, without exception. The same capacity that could fix high-frequency trading abuse could enforce social conformity. Foucault's Panopticon</a> again, but now it's watching for spirit-of-the-rule violations, not just rule violations.</p> China's social credit system is the preview everyone points to. But what makes it troubling isn't really the LLMs; it's the values encoded in the system and the absence of any check on those values. An AI-mediated society with strong civil liberties, democratic oversight, and genuine recourse mechanisms could look different. The problem isn't LLMs in institutions. The problem is arriving at AI in institutions without considering the oversight layer that makes it legitimate.</p> What the oversight layer would actually look like is worth speculating about concretely, because the abstract version ("democratic oversight," "civil liberties") doesn't do the work. Consider a different model: a standing deliberative body, convened not to pass a law but to build a model. Citizens, drawn like jurors from the community that will live under its decisions, spend weeks deliberating over the values they want encoded in the AI systems that govern them. What counts as fair hiring in this jurisdiction? What level of past conduct should stop counting against someone? When does pattern-of-behavior monitoring become surveillance? The outputs aren't statutes. They're preferences: training data, principles expressed in the form that AI systems can actually consume.</p> Deliberative polls have extracted considered judgments on contested issues across dozens of countries. The missing piece, if AI is going to be deployed broadly through society, isn't any single technology or institution; it is a process with democratic legitimacy, subject to ongoing audit and revision by the community that created them. None of that is technically impossible. What it requires is deciding that the legitimacy problem is real: that the question "whose values are encoded?" deserves a democratic answer rather than being settled by whichever research team's cultural assumptions happened to shape the reward model.</p> Meanwhile, the panopticon isn't a hypothetical—it's being assembled now, not through any deliberate plan but through a thousand independent procurement decisions nobody is watching. Automated systems determine benefits eligibility, flag suspected fraud, set insurance rates. Courts use risk assessment tools in bail hearings and sentencing. Facial recognition runs in transit systems and public spaces. Palantir's Gotham platform</a>, deployed across hundreds of law enforcement agencies, lets an officer start from a single name or license plate and retrieve email addresses, phone numbers, bank accounts, Social Security numbers, and family relationships, then auto-track every person in the resulting network. In 2025, ICE awarded Palantir a $30 million contract to build ImmigrationOS</a>, integrating travel histories, biometrics, social media, Medicaid records, IRS data, and license-plate readers into unified AI-driven profiles on individuals, drawing on data from agencies with no legal mandate to share it for immigration enforcement. Flock Safety</a>, now deployed across more than 5,000 communities, operates a national network of license-plate readers that passively logs every vehicle's movements—data pooled across jurisdictions and queryable by any participating law enforcement agency with no warrant required. Real-time crime centers</a>, now operational in dozens of major cities, aggregate these feeds alongside gunshot-detection sensors, surveillance camera networks, and social media monitoring into unified analyst dashboards, converting what were once separate procurement decisions into something approaching continuous observation of public space. Each piece was someone solving their own problem: the agency wanted better tools, the vendor had a product, the contract got signed. Most people living under it have no idea it's there. The totalizing attractor doesn't need a master plan. It just needs everyone to keep optimizing locally while no one asks what they're building together.</p> There is a version of this that resolves toward the contextualizing attractor, not the totalizing one. The failure mode of metric-based institutions is that they treat people from different contexts as if context didn't exist: the same credit score formula applied everywhere, the same sentencing guideline regardless of circumstance, the same test score as the measure of a student. This produces a particular kind of injustice: technically consistent, contextually blind. The promise of AI-native institutions, properly governed, is something different: systems that can see context and still aspire to consistency. A sentencing model that can hold the full circumstances of a case and still be audited for disparate outcomes</a> across race or class (the kind of structured algorithmic audit that Sandvig, Hamilton, Karahalios, and Langbort developed as a research methodology precisely for detecting discrimination in opaque systems). An admissions system that can evaluate a student's actual trajectory rather than their GPA, without the nepotism that currently fills the gap when human "holistic review" becomes cover for preference. These aren't guaranteed improvements. But they describe a real possibility that metric-based systems, by design, can never achieve: judgment that travels with</em> its context rather than by stripping it away.</p> Conclusion</h2> The accidental regulator (TSMC's yield rates, grid interconnection queues, the fact that 3nm lithography is hard) bought us time. We didn't earn it. Every efficiency breakthrough DeepSeek finds, every fab TSMC opens, every GPU off the production line is time running out on a clock we never started.</p> The public discourse about what to do with that time has been captured by the AGI question: will it be conscious? Will it take over? Will it kill us? These are the wrong questions. Every institution that deploys an AI-based system is already operating under data-as-law, whether or not anyone named it that. The training corpus is already the constitution. The rater pool already encoded preferences.</p> This is the thing the extinction discourse spent a decade not asking. It isn't about superintelligence. It doesn't require AGI. It's happening with the systems that exist right now, at the scale they're deployed right now, in the institutions that are quietly replacing spot-checks with models nobody voted to build. The facade of the AGI debate makes it easy to defer: we'll govern this once it gets serious. It's already serious. The governance gap isn't ahead of us. It opened the moment the first procurement decision was made.</p> The new rules aren't written down anywhere. That's the point. Data is law, and unlike every previous form of law, you cannot read it, cannot cite it, cannot challenge it in court. It has no preamble stating its purpose. It has no amendment process. The US military used Claude to select over 1,000 targets in the first 24 hours of strikes on Iran</a>—all run through weights shaped by a rater pool nobody voted to convene, applying values nobody publicly deliberated, with no written record of what was decided or why. It does not know what it got wrong. The cognitive scarcity that forced institutions to strip context out of judgment is dissolving, and the thing replacing it could finally restore that context or it could be the most complete instrument of control ever assembled, enforcing not just rules but norms, not just laws but the full shape of whoever's training data happened to dominate.</p> Scaling laws for capabilities exist because someone decided to run the experiments: vary the compute, measure the loss, find the curve. We don't have societal scaling laws because we haven't run the equivalent experiments. Some of them are obvious enough to start. LLMs are not inscrutable technology. Even if we don't know how it works, we know how to make it. We can develop societal practices around it. What happens when RLHF is treated like a vote — with franchise requirements, transparency, and an auditable record of what was decided? What does training data look like when it goes through a deliberative assembly instead of a contractor's annotation queue? What if democratic AI weren't a slogan but a methodology: citizens' assemblies that produce preference specifications, small-scale pilots in low-stakes institutions, iterated and measured? The point isn't that any of these would work. The point is that we don't know, because nobody is trying. The labs run thousands of ablations to understand what changes a model's capabilities. Nobody is running ablations to understand what changes a society's trajectory. That asymmetry isn't inevitable. It's just where we chose to put the resources.</p> Lots of different LLM based tools were used in the writing and research for this essay</p> </blockquote> SWE Automation Is the Killer App Unknown — Sun, 08 Feb 2026 00:00:00 +0000 The UI Moment, Again</h1> In November 2022, ChatGPT's launch felt like a paradigm shift</a>. Suddenly, everyone was talking about AI. The technology press couldn't stop writing about it. Your relatives asked you about it at Thanksgiving. It seemed to appear overnight.</p> But it didn't appear overnight. Large language models had existed for years. GPT-3 launched in 2020. BERT came out in 2018. The transformer architecture that powers all of this dates back to 2017. Researchers had been steadily improving these systems, publishing papers, iterating on architectures, scaling up training runs.</p> What changed in November 2022 wasn't the underlying technology. It was the interface</strong>. ChatGPT put a language model behind a chat interface and let anyone use it for free. No API keys, no Python notebooks, no papers to read. Just a text box and a conversation.</p> That interface unlocked something. It made the capability legible to non-researchers. People could feel</em> what the model could do by talking to it. The chat format was familiar—everyone texts, everyone uses messaging apps. Within that familiar frame, the AI's capabilities became visible. It could write, reason, explain, code, analyze. The technology had been there, but the interface made it undeniable.</p> This is how technologies break out of research labs. Not through incremental improvements to benchmarks, but through interfaces that make capabilities viscerally obvious to normal humans.</p> The Industry Is Stumbling Around in the Dark</h2> Since ChatGPT's launch, we've seen an explosion of AI applications. Every software category has been AI-ified:</p> Search</strong>: Perplexity, ChatGPT search, Bing Chat</li> Writing assistants</strong>: Notion AI, Google Docs AI, Grammarly</li> Image generation</strong>: Midjourney, DALL-E, Stable Diffusion</li> Video generation</strong>: Sora, Runway, Pika</li> Voice</strong>: ElevenLabs, voice cloning, AI podcasts</li> Music</strong>: Suno, Udio, AI-generated soundtracks</li> Customer service</strong>: AI chatbots on every website</li> Personal assistants</strong>: Replika, Character.AI, custom GPTs</li> Education</strong>: Khan Academy's Khanmigo, Duolingo Max</li> Design</strong>: Figma AI, Canva AI, Adobe Firefly</li> Productivity</strong>: Mem, Notion AI, meeting transcription</li> Code</strong>: GitHub Copilot, Cursor, Claude Code, Devin</li> </ul> The list goes on. There's an AI tool for everything. Venture funding has flooded into AI startups. Every company is adding "AI-powered" to their feature list. We're in the hype phase.</p> What Sticks?</h2> But hype cycles pass. The question isn't what's hot right now, but what remains when the novelty wears off. What application of LLMs is so fundamentally valuable that it becomes infrastructure? What's the killer app that justifies all this investment and attention?</p> The answer is software engineering automation</strong> because it's the one where:</p> The value is measurable</strong></li> The users are willing to pay</strong></li> The technology is good enough</strong></li> The feedback loops are strong enough that the tech doesn't need to be perfect</strong></li> It compounds: better tools make better tools</strong></li> </ul> The Value Is Measurable</h3> Most AI applications exist in fuzzy value territory. Is an AI-generated image "better" than one you'd commission from an artist? Depends on your taste. Does an AI writing assistant make you a better writer? Hard to say, maybe you'd have written something better yourself given time. They maybe faster to make on the surface but they are still distingushable from human images and text enough that you may spend as much time fixing them up as it took to make it from scratch.</p> Software engineering is different. The value is concrete:</p> Did the code work?</strong> Yes or no. It either compiles, passes tests, and does what it's supposed to, or it doesn't.</li> How fast was it delivered?</strong> You can measure velocity—features shipped per sprint, time from spec to deployment.</li> How many bugs were caught?</strong> Fewer production incidents, faster debugging cycles—these are trackable metrics.</li> </ul> There's no subjectivity. If an AI coding assistant lets you ship twice as fast and produce the same results, that's not a matter of taste. It's a measurable business outcome.</p> And the business outcomes are enormous. Software engineering is expensive. Senior engineers at tech companies make $300K–500K+</code> total comp. At scale, even modest productivity gains are worth millions. If an AI tool makes a 100-person engineering team 20% more productive, that's like adding 20 engineers—$6–10M</code>year in value.</p> Companies will pay for that. They already are.</p> Users Who Are Willing to Pay</h3> Consumer AI applications face a harsh reality: users expect AI to be free. In the long term, it will be "free"</strong> . Costs for power, maybe some hardware, but you won't subscribe to some service. Fundamentally, there are few moats in AI. The data is largely publicly available (give or take discussions of fair use). The model architectures for LLMs are publicly disclosed. The fundamental gatekeeper is access to compute. Even then, through techniques like model distillation and quantization, the vast majority of capability can be captured and run on very limited hardware. The current barriers for self-hosted consumer AI come down to ease of setup, use, and maintenance (another UI revolution yet to come). But as many who have instituted paywalls (newspapers, apps, etc.) have found, even charging one cent for your service causes a drastic reduction in your userbase. I fully expect that in the long term, consumer AI will be serviced by something akin to a personal AI computer, a device you'd buy from a manufacturer like Apple that gives you a simple interface to a local model that feels no worse than the trillion-parameter Opus-class models running in datacenters.</p> Businesses have a different value calculus and are far less cost-sensitive. Time and human capital are as important as dollars. Being able to move faster with fewer resources is worth the extra monetary cost. SaaS as a business model has demonstrated this. Workday, Justworks, JIRA, Slack, Tableau, all companies that automate common business functions, allowing companies to have less support staff, move faster, and coordinate better. This doesn't mean you don't have HR specialists or project managers or accountants or data analysts, but you certainly don't need as many.</p> For a long time, software engineering was an exception. It was a high-skill job, and for the most part you could never have enough great engineers. But with tools like Claude Code, one senior engineer with clear intention can implement a feature that used to take a month and a few junior implementers. A $20</code>/month AI coding assistant that saves even an hour per week is worth 10x its cost for an engineer making $150K</code>/year. There's also a management aspect: regulating access to codebases and infrastructure, enforcing best practices. Having a company-wide provider of AI services allows some semblance of control and guarantees about how employees conduct their work.</p> The Technology Is Good Enough</h3> Many AI applications are still in the "impressive demo, rough product" phase. AI-generated video is stunning for 10 seconds, then the physics break. AI music sounds plausible until you listen carefully. AI search is great until it confidently hallucinates.</p> Code generation has crossed a threshold. It's not perfect, but it's useful right now</strong>. Why is code different? A few reasons:</p> Verification loops</strong>: Code either runs or it doesn't. Tests pass or fail. The compiler catches type errors. There's immediate, deterministic feedback that lets the AI iterate toward correctness. This is unlike creative tasks where "correctness" is subjective and subtly encoded into the product.</p> Massive training data</strong>: Code is public (GitHub, Stack Overflow), structured, and abundant. LLMs have seen millions of repositories and billions of lines of code. They've learned patterns deeply.</p> Clear intent from context</strong>: When writing code, the surrounding context—existing functions, type signatures, comments, variable names—provides strong signal about what should come next. The AI isn't generating from a blank slate.</p> Tolerance for iteration</strong>: Developers already iterate. Writing code is revising code. An AI that generates something 80% right that you refine is still a massive win. You don't need perfection, just a good starting point.</p> This combination means code generation is past the toy phase. It's delivering real value in production workflows today.</p> Feedback Loops Provide Leniency to Imperfect Systems</h3> This might be the most important factor. AI coding assistants achieve tasks via feedback. Where there's a strong pass-or-fail signal, with enough iteration an AI agent can solve the problem to some degree.</p> Compare this to other AI applications:</p> AI art</strong>: Users either like an image or they don't. Taste is subjective. Hard to use that to improve the model systematically.</li> AI writing</strong>: Did this make the writing "better"? Hard to measure. Most users can't articulate why they prefer one version over another.</li> AI search</strong>: Did the answer satisfy the user? Maybe they closed the tab because they found what they needed, or maybe because the answer was wrong. Ambiguous signal.</li> </ul> Even when users have preferences, you end up with what we see in consumer-facing chat interfaces: degenerate behavior like sycophancy gets reinforced even when humans know it's suboptimal. People love having their egos stroked, and due to how models trained against human feedback this behavior gets reinforced.</p> Code has ground truth. The compiler and tests are the judge. This lets AI coding tools improve faster than other applications.</p> Additionally, the code generation task aligns with LLM strengths. LLMs are pattern-matching engines trained on vast amounts of text. Code is structured, pattern-rich, and well-represented in training data.</p> It Compounds—Better Tools Make Better Tools</h3> AI coding assistants make themselves better.</p> The teams building Cursor, Claude Code, and GitHub Copilot use their own tools. This use case is being dogfooded more than any other at the companies developing LLMs. As people say in product design, the best products are the ones you make for yourself.</p> This is a compounding loop that doesn't exist for most AI applications. AI-generated art doesn't help you build better art generators—it probably makes them worse. AI writing assistants don't make it easier to train better writing models. But AI code generation directly accelerates AI research and development.</p> This suggests a future where AI-powered software development accelerates—not because models get bigger (though they will), but because the tools for building models get more targeted on this use case, where the feedback signals are most observable.</p> The Staying Power</h2> When the current AI hype cycle cools, what remains?</p> Some consumer AI apps may stick. Chat-mediated research probably survives. AI-generated art may become a standard tool for certain creative workflows, particularly in marketing where art is commodified. Voice AI for transcription and customer service likely becomes commodity infrastructure.</p> But I think the most durable, highest-value application is software engineering automation. This doesn't mean programmers disappear. It means programming changes. The job shifts from writing every line by hand to directing AI systems, reviewing their output, and focusing on architecture and intent. The cognitive load moves up the stack.</p> But unlike other AI applications that might be fads, coding automation has staying power because it's embedded in the critical path of building everything else. Every software company, every tech product, every digital service—they all need code. Making that code faster and cheaper to write is valuable to everyone.</p> The Interface Moment for Coding Agents</h2> Just like ChatGPT made LLMs legible to the general public through a simple chat interface, we're approaching an interface moment for coding agents.</p> Until recently, AI coding tools were mostly autocomplete-plus. Copilot suggests the next line. Cursor helps you edit faster. These are powerful, but they're incremental improvements to existing workflows.</p> The interface moment is here: the abstraction level is shifting. Instead of writing code and having AI assist, you describe intent and AI generates working systems</strong>. The unit of work isn't "write this function" but "build this feature" or "refactor this architecture."</p> When this interface matures, when the abstraction is natural and the reliability is high enough that you trust it, that's when coding automation becomes truly sticky. Not just for early adopters and AI enthusiasts, but for every engineer, every team, every company, normal people</strong>.</p> Conclusion</h2> ChatGPT's launch wasn't about new technology. It was about making existing technology legible through the right interface. The chat box made LLM capabilities undeniable to millions of people.</p> Coding agents follow the same pattern. The technology isn't new or novel. What's coming is the interface refinement that makes software engineering automation natural and reliable. It will also expose software engineering to people who have no clue how to write a single line of code or what a command line is.</p> It's no longer a novelty or a power-user tool. It will be infrastructure—the default way software gets built.</p> That's the killer app. The one that remains when the hype fades. The one that justifies the investment, the attention, and the transformation.</p> The Definition of Good Software Ergonomics Has Changed Unknown — Thu, 05 Feb 2026 00:00:00 +0000 The Vibe Coding</del> Automated Programming Revolution</h1> Software engineering is fundamentally changing. AI coding agents like Claude Code have put the vision of just telling a computer to do something in natural language and it just working out of the box in sight - the kind of natural language computer interface</a> that Star Trek: The Next Generation and other science fictionpromised decades ago. This approach emphasizes directness and velocity over precision. You describe what you want, the AI generates something close, you iterate until it feels right.</p> However, as we embrace more stochastic, probabilistic code generation, the need for deterministic, pedantic verification systems has become more critical, not less. The definition of good ergonomics in software tools has fundamentally changed. "Annoying and verbose" type systems that once felt overly burdensome are now precisely what makes automated programming viable for production systems.</strong></p> The Old Ergonomics: Flexibility vs. Safety</h2> Python/JS: Maximal Expressiveness</h3> For decades, languages like Python, Ruby, and JavaScript defined "ergonomic" programming. They clearly made design decisions prioritizing:</p> Rapid prototyping</strong>: Write code without upfront type declarations or boilerplate</li> Low friction</strong>: No compiler to satisfy, just run your code and see what happens</li> Expressiveness</strong>: Duck typing lets you write generic code without ceremony</li> Approachability</strong>: New developers could be productive quickly</li> </ul> The goal a lot of programmers have is "what is the shortest path to getting something running". And Python and JavaScript are great choices for this because of their flexibility.</p> This made perfect sense when humans were the primary authors. We have the full context of what we just wrote and over time this knowledge grows, so we can make informed decisions about additions or subtractions from the programs. We intuitively understand types from variable names and usage patterns. We catch obvious mistakes as we go. The cognitive overhead of static types felt like friction against our natural workflow. Python became the language of ML precisely because of these properties. When you're iterating on model architectures or experimenting with data transformations, you want to think about the problem, not satisfy a type checker.</p> The Deal We Made with the Devil</h4> But this flexibility came with costs that we grudgingly accepted:</p> Runtime surprises</strong>: AttributeError</code>, TypeError</code>, KeyError</code> appearing in production</li> Refactoring anxiety</strong>: Changing a function signature requires manually hunting down all call sites</li> Integration fragility</strong>: Connecting components means carefully reading documentation and hoping you followed the library and language right</li> Testing burden</strong>: You need comprehensive test coverage just to catch new bugs</li> </ul> We built elaborate defensive strategies: extensive unit tests, runtime assertions, careful code reviews, gradual typing systems like TypeScript and mypy. But fundamentally, we relied on human vigilance to catch what the language wouldn't.</p> This was manageable when humans wrote all the code. We could be careful. We understood our codebases. We had context.</p> Rust: Maximal Safety</h3> Consider the common complaints about Rust today. Developers constantly cite "fighting the borrow checker"</a> as a major pain point. Lifetime annotations are confusing. The compiler is pedantic about ownership and mutability in ways that feel unnecessarily restrictive. You write what seems like perfectly reasonable code and the compiler rejects it with cryptic error messages about borrowed values not living long enough. Simple tasks that take five minutes in Python require 30 minutes of appeasing the type system. The learning curve is brutal.</p> All of this is true when a human is writing Rust character by character. The cognitive overhead of tracking ownership, satisfying lifetime requirements, and structuring code to make the borrow checker happy is immense. You're trying to solve a problem while simultaneously managing low-level memory safety invariants.</p> But with AI-assisted development, this dynamic inverts completely. The LLM doesn't experience cognitive overhead from the borrow checker. It will happily try 20 different lifetime annotations until one works (provided youre willing to pay for the tokens). It doesn't get frustrated when the compiler complains about moving a value that's still borrowed. It just generates a new version. The "fighting the borrow checker" experience - which exhausts humans - is exactly what LLMs are built for: rapid iteration against deterministic feedback.</p> // You: "create a user service that fetches users and validates email"</span></span> // AI generates, borrow checker complains, AI regenerates, repeat 15 times...</span></span> // You see only the final result:</span></span> </span> fn</span> get_user</span>(</span>id</span>:</span> UserId</span>)</span> -></span> Result</span><</span>User</span>,</span> Error</span>> {</span></span> // ... implementation</span></span> }</span></span> </span> fn</span> validate_email</span>(</span>user</span>:</span> User</span>)</span> -></span> bool</span> {</span></span> // ... implementation</span></span> }</span></span> </span> fn</span> process_user</span>(</span>id</span>:</span> UserId</span>)</span> -></span> Result</span><(),</span> Error</span>> {</span></span> let</span> user</span> =</span> get_user</span>(</span>id</span>)</span>?</span>;</span></span> // AI accidentally tries:</span></span> validate_email</span>(</span>user</span>.</span>email</span>)</span> // COMPILE ERROR: expected User, got String</span></span> // AI immediately fixes:</span></span> validate_email</span>(</span>user</span>)</span> // ✓ compiles</span></span> }</span></span></code></pre> The compiler catches that the agent initially mixed up user.email</code> and user</code>. No runtime error in production, no unit test needed for this specific case. The type system caught it mechanically, the AI fixed it automatically, and you never saw the 15 iterations it took to satisfy the borrow checker.</p> The complaints about Rust's difficulty are really complaints about the human experience of satisfying its strict requirements. But those strict requirements are precisely what make it ideal for AI-generated code. The pain points for humans become verification points for AI.</p> Declarative Infrastructure: The Nix Example</h3> The same pattern extends beyond code to systems management. Declarative, reproducible infrastructure tools like Nix represent another case where what seemed like excessive rigor for human operators becomes ideal for AI agents.</p> Traditional imperative systems administration - running sequences of apt install</code>, systemctl enable</code>, editing config files, hoping everything works - is error-prone and fragile. It works when experienced sysadmins carefully maintain mental models of system state and manually verify each step. But it's a nightmare to automate reliably because there's no verification that the system ended up in the desired state. Tools like Ansible improved on raw shell scripts by adding idempotency and a declarative veneer, but they still operate imperatively under the hood - checking current state, computing diffs, applying changes. When an Ansible playbook fails halfway through, you're left with partial state and have to reason about what succeeded and what didn't.</p> Nix flips this model. You declare what you want: Python 3.11, PostgreSQL 15, these exact library versions, with these configuration files</em>, and Nix handles the how. More importantly, Nix provides strong guarantees: builds are reproducible, rollbacks are atomic, different configurations can coexist without conflict. The system either successfully reaches the declared state or fails clearly, with no partial success states. However, many decry Nix's obtuse syntax</a> and steep learning curve. Many developers take one look at Nix and decide apt install</code> is good enough. They want to think imperatively not wrestle with recursive attribute sets and mkDerivation</code> functions.</p> Consider asking an AI to write a bash script that installs dependencies, configures services, and sets up an environment. The AI has to reason about: What packages are already installed? What version? Will this conflict with something else? Did the previous step succeed? Is the service already running? Every system is unique. The AI generates plausible commands that might work, but verification requires actually running them and seeing what breaks.</p> With Nix, the AI writes a declarative configuration. The Nix evaluator immediately catches errors. When you build it, you get exactly what was declared, reproducibly, every time. The AI handles the ceremony of Nix syntax and package resolution while the human specifies intent. The declarative substrate provides verification that what gets built matches what was intended.</p> With AI agents, you can have it both ways. You express your intent imperatively and naturally: "Install PostgreSQL 15, create a database called 'myapp', set up connection pooling with 20 max connections, and configure it to start on boot." The AI translates this into proper Nix configuration handling the syntax, looking up the right package attributes, structuring the configuration options correctly, managing the boilerplate. You think imperatively, the AI writes declaratively, and Nix verifies the result.</p> This inverts the traditional adoption barrier. Instead of having to learn Nix before you can use it, you can use Nix from day one by expressing what you want in plain language. The weird syntax and verbose boilerplate become the AI's problem, not yours. You get the benefits of declarative, reproducible infrastructure without having to master the tool itself.</p> The same applies to all the declarative tools that have better properties but worse ergonomics: Terraform's HCL, Kubernetes manifests, etc. They're all better than imperative alternatives for reproducibility and verification, but they're harder to learn and more verbose to write. AI bridges this gap: you work imperatively, the AI generates declaratively, and the declarative substrate provides verification.</p> Why This Matters Now: Enter Stochastic Code Generation</h2> Now instead of writing code character by character, we describe what we want and receive entire functions, classes, or modules. This is incredible for productivity, but it introduces new failure modes:</p> Plausible but wrong</strong>: AI generates code that looks right but has subtle bugs</li> Inconsistent assumptions</strong>: Different sections of AI-generated code may make incompatible assumptions about data types</li> Naming mismatches</strong>: Field names, parameter names, method names might be close but not quite right</li> Silent type mismatches</strong>: Passing string</code> where int</code> was expected, or vice versa</li> Lost context</strong>: AI doesn't always maintain type consistency across the codebase</li> </ul> When a human writes user.email</code>, they remember that user</code> came from a database query two lines ago and has specific fields. When AI generates it, it's making a probabilistic guess based on prior context for that particular session. That guess is often right, but not always.</p> The same flexibility that made Python ergonomic for human-written code becomes treacherous for AI-generated code. The AI can't "just know" the types the way a human author might, just the same way a fresh new grad being thrown a codebase needs time to understand its subtle behavior, the nuances of the language that the codebase exploits / abuses. Agents without that long form persistent experience do the best they can, sample from a distribution of valid completions.</p> TypeScript's Evolution</h3> TypeScript's adoption trajectory shows us a preview of this future. When it launched in 2012, many JavaScript developers saw it as "unnecessary"</a> ceremony. JavaScript was already working fine,why add all this type annotation boilerplate? The tooling was immature. The type definitions for popular libraries were incomplete or wrong. Developers complained about having to write interface</code> declarations for every data structure and explicitly type every function parameter.</p> The turning point came as codebases scaled. When teams grew beyond five people, when code lived longer than six months, when people joined and left organizations, the lack of static checking and other mechanistic verification became a liability. You couldn't rely on humans having perfect context about all the nuances of the codebase. A new hire looks at a function that returns data</code>, has no idea what shape that data has, and makes an incorrect assumption that ships a catastrophic bug into production.</p> TypeScript solved this by making the implicit explicit. Types serve as documentation that the compiler enforces. When someone changes a function signature, every call site gets flagged. When you hover over a variable in your editor, you see exactly what it is. The "unnecessary ceremony" turned out to be essential scaffolding for teams and time scales.</p> Now with AI coding assistants, TypeScript's value proposition has intensified. LLMs generate more accurate code when they have type information to guide them, using types as contracts to ensure correctness. The types that made human collaboration scalable now make human-AI collaboration reliable.</p> Why Runtime Errors Are Worse for AI-Generated Code</h3> Running code to discover errors is orders of magnitude slower than compile-time checking. When an LLM generates code, waits for it to run, encounters a TypeError</code> on line 47, and has to regenerate. Compile errors return in milliseconds. Runtime errors require executing code, potentially setting up test environments, databases, or external dependencies. The AI might need to generate and run code multiple times to catch all the runtime errors that static analysis would have caught immediately. In AI development in particular, runs can be on the order of months. So either you must spend a lot of effort verifying each AI generated piece of code, or you pray that in 2 weeks you wont have a crashed training run. Runtime errors also leave your system in an unknown state. Did the database transaction commit? Did the file get written? Did the message get sent? The AI has no memory of what side effects occurred before the error, making it hard to reason about what needs to be cleaned up or retried. Runtime errors can depend on execution paths, data, and timing. The same AI-generated code might work with one set of inputs and fail with another. It might work in development and fail in production. The LLM might successfully generate code that passes initial tests but contains latent bugs that only appear under specific conditions. Type systems catch these categories of errors unconditionally. In dynamically typed languages, one type error can cascade into many runtime errors. The AI fixes the first error, runs again, hits a second error caused by the same underlying type confusion, fixes that, runs again, hits a third error. With static types, all related errors are caught simultaneously, and fixing the type definition fixes all of them at once. AI coding assistants amplify both the productivity gains of flexible languages and their risks.</p> The New Ergonomics: Flexibility + Safety</h2> This is where formally verified and compiler-verified systems become essential. Languages like Rust, OCaml, Haskell, and even modern TypeScript provide something critical: automated, mechanical verification that generated code is internally consistent</strong>.</p> The new ergonomic ideal is this: be loose and viby with intent</strong>: ideas, features, specifications, but strict and pedantic with verification</strong>. This is where previously "annoying" tools like static analyzers, linters, and type checkers play a crucial role. Good software software written with these agentic tools needs to be self-verifying. Ideally in addition to using a programming language with strong type checking, the codebase itself should be imposing additional contract layers to ensure that new code integrates as expected.</p> Why Pedantic Systems Are Perfect for AI-Assisted Coding</h3> The pairing of AI code generation with strong type systems exploits a fundamental asymmetry in capabilities. LLMs are remarkably good at iterating rapidly through compiler errors without fatigue, pattern matching against type signatures to generate syntactically valid code, and exploring large search spaces of possible implementations. They maintain perfect patience through dozens of compile-fix cycles, never getting frustrated or bored. An LLM will happily regenerate code 20 times to satisfy the borrow checker or fix a type mismatch.</p> But LLMs are comparatively poor at catching subtle semantic bugs that compile correctly, understanding deep business logic and domain invariants, reasoning comprehensively about edge cases and error conditions, or maintaining consistency in intent across a large codebase. These require contextual understanding and judgment that current models lack.</p> This creates a clear division of labor. Strong type systems and compiler verification provide quick, theoretical guarantees about structural correctness, exactly the kind of mechanical feedback that LLMs can iterate against efficiently. The compiler provides immediate, precise feedback that guides the generative process toward valid implementations. The LLM fights through the pedantic mechanical details that would exhaust a human developer.</p> Meanwhile, those same type systems won't catch that you're calculating the discount incorrectly, that you forgot to handle the case where a user account is suspended, or that your algorithm has the wrong complexity for the scale you need. These subtle implementation issues require human review and domain knowledge. This points to what next-generation programming interfaces must solve: surfacing business logic and domain invariants clearly and explicitly, rather than allowing them to be scattered implicitly throughout the codebase. When the critical logic is concentrated and visible, humans can effectively review what matters. The type system details, the mechanical plumbing, the syntactic correctness become increasingly hidden from the human developer, the same way most people don't read the assembly for their programs. Its main role now is as feedback for the LLM during implementing a new set of business logic. Part of this work will also be implementing higher order contract verfication into the codebase so that as new additions are made, conflicts can be surfaced prior to deployement.</p> This suggests a future where programming interfaces have two distinct layers: a dense, type-rich substrate that the LLM interacts with directly, and a higher-level interface where humans specify intent, business rules, and constraints. The human never sees the 40 iterations the LLM took to satisfy the borrow checker. They see the business logic they specified, and tools that help them verify it does what they intended. The type system becomes infrastructure - essential, but largely invisible to the human operator.</p> This isn't just speculation - this pattern is already being deployed in production systems where correctness is life-or-death critical.</p> Real Deployments: Stochastic Generation + Deterministic Verification Today</h2> Dual Verification in Safety-Critical Systems</h3> This pattern of dual-system verification isn't hypothetical, it's already deployed in autonomous vehicles. NVIDIA's DRIVE platform for autonomous vehicles</a> exemplifies this architecture. The system runs two parallel stacks: an end-to-end AI-based autonomous driving system (increasingly powered by models like Alpamayo</a>, which uses vision-language-action models to reason about complex driving scenarios) and a traditional safety verification system.</p> The AI system is generative and stochastic, making probabilistic decisions about steering, acceleration, and navigation based on sensor inputs. It can handle novel situations and reason through edge cases like navigating a traffic light outage, but its decision-making process is fundamentally opaque. The safety system, in contrast, uses traditional formal verification methods that check whether the AI's proposed actions violate safety constraints.</p> The result is exactly the pattern we've been discussing: a stochastic generative system (the AI driver) paired with deterministic verification (the safety stack). The AI explores the solution space creatively, making real-time decisions. The formal verification system checks those decisions against hard constraints such as occupancy, speed limits, and traffic rules. The AI can propose novel solutions to complex problems, but only actions that pass formal verification get executed.</p> This is the template for AI-assisted development writ large. The generative system proposes, the verification system validates, and humans review the semantic correctness at a high level. When your car's autonomy stack makes a decision, you want the same confidence you get from a type-checked program: the mechanical details have been verified, so you can focus on whether the high-level behavior matches your intent.</p> Formal Methods and Theorem Proving</h3> For critical systems, we're seeing interest in even stronger verification: formal methods like dependent types (Idris, Agda), proof assistants (Coq, Lean), and specification languages (TLA+, Alloy).</p> These tools let you specify invariants and properties that must hold, and mechanically verify that your code satisfies them. This was previously seen as too expensive for most software, but when AI can help generate both code and proofs, the cost-benefit calculation changes.</p> The recent breakthroughs in AI-assisted theorem proving demonstrate this isn't hypothetical. Google DeepMind's AlphaProof achieved silver-medal performance at the 2024 International Mathematical Olympiad</a> by proving mathematical statements in Lean. More recently, they achieved gold-medal performance in 2025</a>. These systems train by proving millions of problems, learning from each verified proof to tackle increasingly difficult challenges.</p> Tools like LeanDojo</a> and Lean Copilot</a> now make this accessible for developers. They provide AI-assisted theorem proving that integrates directly into the Lean workflow, with over 210,000 theorems already formalized in mathlib as of 2025. The AI generates proof candidates, the Lean proof assistant verifies them mechanically, and the process iterates until a valid proof is found.</p> This is the same pattern: you specify what properties your system should have (the theorem statement), AI explores the solution space (generating proof candidates), and formal verification ensures correctness (Lean checking each proof). The difference is that instead of catching type errors, you're proving algorithmic correctness, data structure invariants, or protocol safety properties.</p> Imagine: you vibe out the high-level requirements and properties your system must satisfy, AI generates an implementation and proofs that it satisfies those properties, and a proof checker verifies everything mechanically. You get the velocity of vibe coding with the confidence of formal verification.</p> The Cognitive Load Shift</h2> The old model:</p> Writing code</strong>: Low cognitive load (flexible, forgiving)</li> Verifying code</strong>: High cognitive load (manual review, testing, debugging)</li> </ul> -- or --</p> Writing code</strong>: High cognitive load (fighting to satisfy the compiler, very slow iteration time)</li> Verifying code</strong>: Low(er) cognitive load (compiler does much of it automatically, but still some manual review, testing, debugging)</li> </ul> The new model:</p> Writing code</strong>: Medium cognitive load (express intent clearly, but let AI handle details)</li> Verifying code</strong>: Low(er) cognitive load (compiler does much of it automatically but still some manual review)</li> </ul> This is a fundamental shift in what programming ergonomics means.</p> What "Ergonomic" Means Now</h3> Good software ergonomics used to mean:</p> Minimal ceremony</li> Flexibility</li> Freedom to experiment</li> Low friction for small changes</li> </ul> Good software ergonomics now means:</p> Minimal ceremony for expressing intent</strong></li> Flexibility in approach</strong>, rigidity in contracts</strong></li> Freedom to experiment with implementation</strong>, strictness in interfaces</strong></li> Low friction for small changes with automated verification</strong></li> </ul> The key insight is that we can have both velocity and safety by separating the stochastic layer (AI generation) from the deterministic layer (type checking and formal verification). Each does what it's good at.</p> Implications for Existing Languages</h2> Today, the choice of tools should be guided by the principles of choosing systems which can enforce correctness and safety, letting LLMs be the interface between the creative high level design decisions (e.g. model architecture choices in a machine learning system) and a deterministic self verifiying implementation. The complaint about Nix flake being too hard to write doesn't make as much sense when the LLM will do it for you and Nix will verify it and all you have to say is "add postgres to my environment".</p> Python's Potential</h3> Python is in an interesting position. It's the language of AI development, but it's poorly suited to AI-assisted application development in its default form. The solution could be more disciplined use of type hints and tools like mypy, Pydantic, and dataclasses. But this only goes so far and requires significant discipline and effort from developers and the LLMs</strong> to verify through those tools.</p> Projects like Mojo</a> and efforts to improve Python's performance also point toward a future where Python gets stricter, not looser, because strictness enables better tooling and verification.</p> But what if we didn't retrofit existing languages? What if we designed a language from scratch for this new paradigm?</p> The Compiler's Job: Verification and Translation</h3> The AI compiler should do several things:</p> Translates intent to implementation</strong>: Natural language becomes properly structured code</li> Generates verification artifacts</strong>: Adds phantom types, lifetime annotations, proofs</li> Enforces contracts</strong>: Ensures all requires</code> and ensures</code> clauses are satisfied</li> Iterates on errors</strong>: When the verification layer rejects code, the AI regenerates until it passes</li> Optimizes silently</strong>: Chooses efficient data structures and algorithms within the constraints</li> Builds internal verification tooling</strong>: Adds progressively more verification to the application to test against new additions that validate the semantic correctness the type system can't guarantee</li> </ol> This last point is crucial. Good LLM-assisted design doesn't just generate code that satisfies a type checker - it also generates the verification infrastructure to check semantic properties. When you specify ensure: vip_users_get_at_least(15%)</code> in your discount calculation constraint, the system should generate property-based tests that verify this holds across thousands of randomized inputs. When you declare invariant: suspended_users_cannot_login</code>, the system should generate integration tests that attempt to authenticate suspended users and verify they're rejected.</p> The LLM can generate both the implementation and the verification tooling in parallel, using the same declarative specifications. Your business logic constraints become executable tests. Your invariants become runtime assertions in debug builds and fuzzing targets. The type system catches structural errors, and the generated verification tooling catches semantic errors.</p> This is another advantage of working at the right abstraction level. When humans write tests, we often skip edge cases or forget to test invariants we assume are obvious. When an LLM generates verification tooling from explicit invariant declarations, it can be exhaustive. It doesn't get bored writing the hundredth property test. It will happily generate comprehensive test suites that check every stated constraint from every angle, because constraints are just another kind of specification to translate into code.</p> The human never sees most compiler errors. The AI iterates in the background until the generated code satisfies all the invariants and type constraints. What the human sees is:</p> ✓ Constraint discount_calculation verified</span></span> ✓ Invariant suspended_users_cannot_login enforced at type level</span></span> ✓ Session lifetime safety proven</span></span> ✓ All authentication paths preserve invariants</span></span></code></pre> Or, if there's a semantic issue the type system can't catch:</p> ⚠ Warning: discount_calculation may overflow for lifetime_value > $9,999,999,999</span></span> Suggest: Add explicit bounds to user.lifetime_value type</span></span> </span> ⚠ Potential performance issue: authenticate() performs O(n) scan on user table</span></span> Suggestion: Add index on email column (migrations/add_email_index.sql)</span></span></code></pre>Properties of AI-Native Languages</h3> This two-layer architecture enables several key properties:</p> For humans:</strong></p> Write mostly declarative specifications</li> See business logic clearly concentrated</li> Get semantic feedback about domain issues</li> The compiler is not your problem</li> </ul> For LLMs:</strong></p> Clear contracts to satisfy through types</li> Rich type system to iterate against</li> Mechanical verification of correctness</li> Freedom to explore implementation space</li> </ul> For the system:</strong></p> Provably correct by construction</li> Performance optimizations without sacrificing safety</li> Refactoring is automated - change a constraint, AI updates all implementations</li> Testing focuses on business logic, not mechanical correctness</li> </ul> The Gap Today</h3> We're not there yet. Current AI coding tools work with languages designed for humans writing code character by character. But the bones of this vision exist: Rust's type system, Liquid Haskell's refinement types, Dafny's verification, even SQL's declarative nature. What's missing is the integration - a language where the human interface is intent and contracts, the machine interface is rich types and proofs, and AI bridges the gap.</p> Early evidence suggests this approach is viable. Anthropic's experience building a C compiler in Rust with Claude</a> demonstrated exactly this dynamic: the LLM patiently iterated through Rust's strict type system and borrow checker, generating code until it satisfied all the constraints. The compiler's mechanical feedback guided the AI toward correct implementations, catching entire classes of bugs that would have been subtle runtime errors in C. The developers focused on architectural decisions and correctness of the parsing logic, while Claude fought the borrow checker.</p> Conclusion: Embracing the Pedantic</h2> This isn't a compromise or a trade-off. It's a synthesis. We get the benefits of flexible, natural-language-driven development without sacrificing correctness or maintainability. We (humans) write less boilerplate than ever, but the underlying code is verified to be consistent.</p> The definition of ergonomic software development has changed. Languages and tools that felt heavyweight in the era of human-only coding are the lightweight choice</strong> in the era of AI-assisted coding. When you didn't write the code yourself, you want as many guarantees as possible. Hoping that an agent writes perfect Python every time is a gamble. The future of programming isn't choosing between velocity and safety - it's using formal systems to verify stochastic processes, and that combination is more ergonomic than either approach alone.</p> An aside: LLMs as an abstraction layer (2/9/26)</h2> Writing assembly is an enlightening experience. Anything is possible, but it's tedious, hard to reason about system state, and errors are easy to make, severe, and difficult to debug (as anyone who has taken ECE 391 at UIUC can attest</a>). The burden of reasoning about system state falls entirely on the programmer. Yet assembly is far preferable to writing raw machine code or having to build an ASIC by hand.</p> The stack machine abstraction built on assembly enables code reuse through strict conventions (like the C calling convention</a>). By imposing limitations through contract—register usage, stack management—two disjoint codebases can be merged to create more complex systems. C adds another abstraction layer with its type system, memory management, and abstract system definition, meaning many developers never need to think about how many bits are in an integer or where a local variable is stored in memory. Objects, methods, and interfaces introduce further contracts that make systems easier to reason about. The operating system provides a common virtual environment for multiple userland programs to interact with hardware concurrently. The GUI offers a graphical language for managing operating system state, creating a more intuitive interface.</p> Each abstraction layer imposes rigid rules on what is allowed that may at first feel limiting, while providing a solid foundation for building higher-order applications. The abstraction layer enforces these rules, ensuring the system remains consistent and predictable. What's missing now is a composable contract system that allows LLMs to expose a higher level of abstraction to developers with the same strong guarantees that existing abstraction layers provide.</p> (Relevant discussion: Software Engineering Past, Present, and Future with Grady Booch</a>)</p> Understanding the Waypoint Transformer Unknown — Sun, 27 Oct 2024 00:00:00 +0000 Waypoint Transformer</h1> The Waypoint Transformer</a> was published at NeuRIPS 2023 by Badrinath et. al. and is a new method for Reinforcement learning via supervised learning (RvS) that builds on the prior Decision Transformer</a> and is conditioned on automatically generated waypoints.</p> Online vs Offline Reinforcement Learning</h3> In reinforcement learning, the agent learns to interact with an environment by taking actions and observing the results. The agent's goal is to maximize the cumulative reward it receives over time. The agent learns by trial and error, exploring the environment and learning from its experiences. There are two large classes of approach to reinforcement learning: online and offline. Online reinforcement learning interacts with the environment in real-time, while offline reinforcement learning learns from collected prior experiences interacting with the environment.</p> Supervised Reinforcement Learning (RvS)</h3> Value-based offline methods tend to attempt to learn a pessimistic value estimate for different states in the state space or state action pairs. This is used to estimate the expected return of a policy. Alternatively, model-based offline RL methods estimate the dynamics of the environment and use it to plan. Typically, complex hyperparameter tuning is required to achieve stable learning.</p> Reinforcement learning via supervised learning (RvS), builds off behavioral cloning as a simple alternative to traditional offline RL. This removes the need for Temporal Difference (TD) learning and value functions and allows offline RL to reuse methods from supervised learning. Typically, the conditioning variable for the policy is based off the return, goal-conditioning, or inverse reinforcement learning,</p> RvS has historically struggled in tasks where the agent must combine multiple sub-optimal training trajectories to achieve a goal. The Waypoint Transformer paper points to two notable examples: reaching specific locations in AntMaze and completing a series of tasks in FrankaKitchen. Here, prior TD methods such as Implicit Q-learning outperform RvS methods.</p> Waypoint Transformer</h2> The Waypoint Transformer introduces a method for generating intermediate goals and more stable proxy rewards that guide the policy towards objectives. Then they use a transformer based RvS method on the generated sub-goals to obtain a policy that learns to follow the waypoints improving performance and stability vs other offline RL methods.</p> Setting</h3> Using the Markov Decision Process (MDP) setting, with states $s_t \in \mathcal{S}$, $a_t \in \mathcal{A}$, unknown dynamics $p(s_{t+1} \| s_t, a_t)$ and initial state distribution $p(s_0)$, the agent chooses an action $a_t \sim \pi_{\theta}(a_t \| s_{t-k..t}, \Phi_{t-k..t})$, parameterized by $\theta$ and conditioned on a known history of states $s_{t-k..t}$ and a conditioning variable $\Phi_{t-k..t}$ that could encode goals or rewards based on a target global outcome $\omega$.</p> This is distinct from the traditional RL setting where the policy is modeled on $\pi(a_t \| s_t)$, as the policy is modeled using a transformer which accepts the past states in a fixed sized context window $k$. The choice of $\omega$ during training is sampled from data. At test time, it is assumed that $\omega$ can be generated or provided by global goal information for a goal-conditioned variant or simply a target reward in the reward-conditioned variant.</p> Waypoints</h3> </p> In offline RL, data typically does not encompass all possible cases that an agent may want to achieve in testing. Consider a infinite dataset $\mathcal{D}$ that is collected by a random behavior policy $\pi_{b}(a_t\|s_t)$. When looking to achieve a goal $\omega = s^{(H)}$, the random policy will be suboptimal since actions are selected at random. Then when using a goal conditioned policy $\pi_{G}(a_t\|s_t,\omega)$ that is trained using demonstrations from $\mathcal{D}$, the policy will also be suboptimal since $\omega$ is fixed, so $\forall s \in \mathcal{S},$ $\pi_{G}(a_t\|s_t,\omega) = \pi_{b}(a_t\|s_t)$. So a global goal-conditioned policy cannot be any better than the random behavior policy it was trained on.</p> Instead consider a policy that uses intermediate goals $\pi_{W}(a_t\|s_t, \Phi_t)$, $\Phi_t = s_{t+k}$. The paper shows that the probability of choosing an optimal action is higher compared to the longer-horizon goal conditioned policy. $\Phi_t$ also serves as a guide as it guides the policy towards strong intermediate targets to reach the global goal. As long as the selected waypoints are strong ones that lead towards the goal $\omega$, the expectation on policy will be more optimal than behavior cloning.</p> Stitching Waypoints</h4> </p> The ability to compose sequences of otherwise suboptimal trajectories requires finding experiences that are more relevant to achieving subgoals vs the overall goal. The paper uses AntMaze to demonstrate this. They find that only 5% of trajectories using a random policy</em> (this is unclear in the paper) would demonstrate how to cross between a start region and the target region. It is therefore very unlikely to find a trajectory that goes from the start state to the goal state. The policy must stitch together trajectories that start at the start state with trajectories that end at the goal state. By providing waypoints in the stitching regions the policy can be guided to connect the relevant sub-sequences together.</p> Generating Waypoints (Goal-conditioned RvS)</h3> The paper uses a waypoint generator that makes $k$ step ahead predictions of future observations conditioned on $s_t$ and $\omega$. This is parameterized as a neural network that is trained on the same offline dataset $\mathcal{D}$ as the policy using MSE loss.</p> $$ arg\min_{\phi} \sum_{(s_t, \omega) \in \mathcal{D}} \|\| W_{\phi}(s_t, \omega) - s_{t+k} \|\|^2_2 $$</p> By doing this you are learning which states $k$ steps ahead you want to visit to reach a goal $\omega$ and then use this to guide the policy. The assumption is that you will have a strong demonstration of the policies to cross $k$ steps from any particular state to other states $k$ steps away.</p> Generating Proxy Rewards (Reward-conditioned RvS)</h3> Prior methods use cumulative reward to-go (CRTG) - a dynamic estimate of the reward to go or average reward-to-go (ARTG) - a static estimate of the reward to go as proxy rewards for the policy. However, using these conditioning variables has drawbacks: the variance of cumulative reward-to-go is high and the bias of the average reward-to-go is high. Instead of using a learned value function like in TD methods, this paper adds a reward waypoint network to estimate both cumulative and average reward-to-go conditioned on $s_t$ and $\omega$ using $\mathcal{D}$. They claim that modeling both CRTG and ARTG addresses the high bias of ARTG and the high variance of CRTG in the same way that prior methods like REINFORCE</a> do.</p> Policy Transformer</h3> </p> The architecture for the waypoint transformer is based on GPT-2. The policy is conditioned on the past $k$ states and the waypoints (either the goals or rewards) $\Phi_{t - k..t}$ which are generated by the waypoint network. The policy transformer is trained using negative log likelihood loss based on data sampled from $\mathcal{D}$. During this process, the waypoint network is fixed. Unlike decision transformers, the waypoint transformer is not conditioned on past actions.</p> Experiments</h2> The proposed method is evaluated on two environments that come with many suboptimal demonstrations in the goal-conditioned case: AntMaze and FrankaKitchen. FrankaKitchen specifically has no end to end demonstrations available. For each of these environments, the paper uses goal conditioning where $\omega = s_{target}$ and constructs intermediate waypoints using the goal waypoint network. For reward-conditioned tasks they use Gym-MuJoCo. For a plurality of evaluated tasks, waypoint transformers outperform decision transformers and other offline RL methods. However there are some cases where TD still outperforms the waypoint transformer or that waypoint transformer simply matches the performance of behavior cloning.</p> </p> The authors analyze the behavior of the waypoint transformer on AntMaze, they find that WT is much more effective at reaching the goal state than a globally conditioned policy and completes the task faster. When using $k = 30$ vs. $k = 0$, the performance is 2.2x worse.</p> On reward conditioned tasks the authors analyze the behavior of the waypoint transformer on Hopper-v2. They find that the standard deviation of CRTG grows slower than other methods. WT is also more robust to the choice of seed than other methods.</p> Interestingly in the appendix, they evaluated using manually selected waypoints and found that WT outperforms manual waypoints. However the manual waypoints are still better than no waypoints and the difference seems to come down to the density of waypoints selected. The manual waypoints are much coarser than the waypoints selected by the waypoint network.</p> Why This Matters</h3> The real usefulness of this method is to be able to collect a lot of partial demonstrations of relevant trajectories, then allow the waypoint network guide the policy to compose them together to achieve a goal in an environment with sparse rewards where traditional RL methods would struggle or would require much higher quality data. RvS is a compelling method for RL since it does not require learning a value function which is incredibly sensitive to initialization and requires a lot of data to learn. The issue with prior RvS methods is that they rely on the quality of the demonstrations to be able to learn a good policy. Behavior cloning and imitation learning methods alone are unable to utilize partial demonstrations as well, requiring demonstrations that fully explain how to achieve a goal. This makes data collection incredibly expensive and time consuming particularly when goal and start states are not fixed. Waypoint transformers demonstrate a method to learn from partial demonstrations and compose them together to achieve a goal. However, waypoint transformers are a method designed to handle degenerate cases. In cases where demonstrations are complete, waypoint transformers are not necessary and their performance will be similar to behavior cloning or decision transformers. This paper focuses on spatial composability and reward interpolation, it is unclear how well waypoint transformers are able to compose over other dimensions such as skill chaining.</p> Building CLIP from Scratch to Classify Pokemon Unknown — Mon, 07 Oct 2024 00:00:00 +0000 Building CLIP from Scratch to Classify Pokemon</h1> Prior deep learning approaches to performing image classification frame the problem as given a dataset of image, label pairs, learn a mapping between the image space and the label space using a neural network (MLP, CNN, etc.). Here the image space is typically a CxHxW dimensional space where C is the number of channels, H and W are the height and width of the input image. Labels may have semantic meaning to us as humans, but are presented to the model simply as one-hot encoded vectors in a fixed sized N-D space where N is the number of possible different labels that can be seen in the dataset. Each dimension of the label space is assigned a distinct possible label, and the models output in that any particular dimension represents the models confidence that the image is of that class. Extremely good performance on classification tasks can be achieved using this problem framing and a good choice of model architecture. However, this framing has drawbacks when trying to move out of narrow independent and identically distributed settings, such as classification of images that are of a class not seen before or dealing with slightly differently formed labels. In such cases, the model is unaware of the existence of anything other than the N classes it was designed to decide between. Even if it was, it would not be able to represent a novel class due to its fixed sized output and the assigned semantic meanings to each dimension.</p> More recently, self-supervised methods have emerged which use simple scalable training tasks to create models that can easily be repurposed for a number of different tasks. Many of these methods avoid the use fixed sized label spaces instead looking to embed representations of different modalities of data in a common embedding space. Distance in this embedding space represents “sameness”. These models look to therefore project tuples of related data into the same area in embedding space. Unseen labels or classes can be projected into this embedding space just as easily as seen data, so even if the model has not seen that exact label before, it its embedding should be close to similar seen labels and consequently their corresponding images.</p> One of these methods is Contrastive Language-Image Pre-training (CLIP). CLIP looks to take image and text pairs such as captions for an image or alt-text and estimate how related they are by this projection into a common embedding space. As opposed to “traditional” classification approaches, CLIP is not attempting to solve the classification problem directly. It instead looks to maximize the cosine similarity between correct image text pairs in the joint embedding space and minimize the similarity between incorrect pairs. CLIP can then be repurposed for classification by giving the model the choice between a number of potential captions (or labels) for an unseen image. The caption with the highest cosine similarity can be considered the class, leading to what is known “open world” object recognition. In this tutorial, we will learn how to create our own CLIP model and use it to classify images of Pokemon.</p> The CLIP Model</h2> The CLIP model consists of a text encoder and an image encoder. Since the ultimate goal is to be able pair image embeddings with their corresponding text embeddings, these two models are trained together to maximize the pairwise cosine similarities between corresponding image and text embeddings and conversely minimize the cosine similarity between image and text embeddings from different pairs.</p> class</span> CLIP</span>(</span>nn</span>.</span>Module</span>):</span></span> def</span> __init__</span>(</span>self</span>,</span> emb_dim</span>,</span> vit_width</span>,</span> img_size</span>,</span> patch_size</span>,</span> n_channels</span>,</span> vit_layers</span>,</span> vit_heads</span>,</span> vocab_size</span>,</span> text_width</span>,</span> max_seq_length</span>,</span> text_heads</span>,</span> text_layers</span>):</span></span> super</span>().</span>__init__</span>()</span></span> </span> self</span>.</span>image_encoder</span> =</span> ImageEncoder</span>(</span>vit_width</span>,</span> img_size</span>,</span> patch_size</span>,</span> n_channels</span>,</span> vit_layers</span>,</span> vit_heads</span>,</span> emb_dim</span>)</span></span> </span> self</span>.</span>text_encoder</span> =</span> TextEncoder</span>(</span>vocab_size</span>,</span> text_width</span>,</span> max_seq_length</span>,</span> text_heads</span>,</span> text_layers</span>,</span> emb_dim</span>)</span></span> </span> self</span>.</span>temperature</span> =</span> nn</span>.</span>Parameter</span>(</span>torch</span>.</span>ones</span>([])</span> </span> np</span>.</span>log</span>(</span>1</span> /</span> 0.07</span>))</span></span> </span> self</span>.</span>device</span> =</span> torch</span>.</span>device</span>("</span>cuda</span>"</span> if</span> torch</span>.</span>cuda</span>.</span>is_available</span>()</span> else</span> "</span>cpu</span>")</span></span> </span> </span> def</span> forward</span>(</span>self</span>,</span>image</span>,</span>text</span>,</span> mask</span>=</span>None</span>):</span></span> I_e</span> =</span> self</span>.</span>image_encoder</span>(</span>image</span>)</span></span> T_e</span> =</span> self</span>.</span>text_encoder</span>(</span>text</span>,</span> mask</span>=</span>mask</span>)</span></span> </span> # scaled pairwise cosine similarities [n, n]</span></span> logits</span> =</span> (</span>I_e</span> @</span> T_e</span>.</span>transpose</span>(</span>-</span>2</span>,</span>-</span>1</span>))</span> </span> torch</span>.</span>exp</span>(</span>self</span>.</span>temperature</span>)</span></span> </span> # symmetric loss function</span></span> labels</span> =</span> torch</span>.</span>arange</span>(</span>logits</span>.</span>shape</span>[</span>0</span>]).</span>to</span>(</span>self</span>.</span>device</span>)</span></span> </span> loss_i</span> =</span> nn</span>.</span>functional</span>.</span>cross_entropy</span>(</span>logits</span>.</span>transpose</span>(</span>-</span>2</span>,</span>-</span>1</span>),</span> labels</span>)</span></span> loss_t</span> =</span> nn</span>.</span>functional</span>.</span>cross_entropy</span>(</span>logits</span>,</span> labels</span>)</span></span> </span> loss</span> =</span> (</span>loss_i</span> +</span> loss_t</span>)</span> /</span> 2</span></span> </span> return</span> loss</span></span></code></pre> If you don’t know what text or image encoders are, you might want to follow a more bottom-up CLIP tutorial that first develops these concepts: https://medium.com/correll-lab/building-clip-from-scratch-68f6e42d35f4</p> Text Encoder</h3> For the text encoder in CLIP we use the standard transformer architecture. However we want to embed features in the joint vision-text embedding space. Therefore we have an extra set of parameters nn.Parameter(torch.randn(width, emb_dim))</code>. In the forward function, the text features are embedded in the joint space by getting the dot product of the features and the learned projection divided by the normalized dot product.</p> class</span> TextEncoder</span>(</span>nn</span>.</span>Module</span>):</span></span> def</span> __init__</span>(</span>self</span>,</span> vocab_size</span>,</span> width</span>,</span> max_seq_length</span>,</span> n_heads</span>,</span> n_layers</span>,</span> emb_dim</span>):</span></span> super</span>().</span>__init__</span>()</span></span> </span> self</span>.</span>max_seq_length</span> =</span> max_seq_length</span> # Maximum length of input sequence</span></span> </span> self</span>.</span>encoder_embedding</span> =</span> nn</span>.</span>Embedding</span>(</span>vocab_size</span>,</span> width</span>)</span> # Embedding Table</span></span> </span> self</span>.</span>positional_embedding</span> =</span> PositionalEmbedding</span>(</span>width</span>,</span> max_seq_length</span>)</span></span> </span> self</span>.</span>encoder</span> =</span> nn</span>.</span>ModuleList</span>([</span>TransformerEncoder</span>(</span>width</span>,</span>n_heads</span>)</span> for</span> _</span> in</span> range</span>(</span>n_layers</span>)])</span></span> </span> # learned proj of image to embed</span></span> self</span>.</span>projection</span> =</span> nn</span>.</span>Parameter</span>(</span>torch</span>.</span>randn</span>(</span>width</span>,</span> emb_dim</span>))</span></span> </span> def</span> forward</span>(</span>self</span>,</span> text</span>,</span> mask</span>=</span>None</span>):</span></span> # Text Embedding</span></span> x</span> =</span> self</span>.</span>encoder_embedding</span>(</span>text</span>)</span></span> </span> # Positional Embedding</span></span> x</span> =</span> self</span>.</span>positional_embedding</span>(</span>x</span>)</span></span> </span> # Transformer Encoder</span></span> for</span> encoder_layer</span> in</span> self</span>.</span>encoder</span>:</span></span> x</span> =</span> encoder_layer</span>(</span>x</span>,</span> mask</span>=</span>mask</span>)</span></span> </span> # Takes features from the EOT Embedding</span></span> x</span> =</span> x</span>[</span>torch</span>.</span>arange</span>(</span>text</span>.</span>shape</span>[</span>0</span>]),</span>torch</span>.</span>sub</span>(</span>torch</span>.</span>sum</span>(</span>mask</span>[:,</span>0</span>],</span>dim</span>=</span>1</span>),</span>1</span>)]</span></span> </span> # joint multimodal embedding</span></span> if</span> self</span>.</span>projection</span> is not</span> None</span>:</span></span> x</span> =</span> x</span> @</span> self</span>.</span>projection</span></span> </span> x</span> =</span> x</span> /</span> torch</span>.</span>norm</span>(</span>x</span>,</span> dim</span>=-</span>1</span>,</span> keepdim</span>=</span>True</span>)</span></span> </span> return</span> x</span></span></code></pre>Image Encoder</h3> For the image encoder we use the standard vision transformer architecture. Similar to the text encoder, we have an extra set of parameters nn.Parameter(torch.randn(width, emb_dim))</code>, the forward function will embed the image features in the joint embedding space by taking the dot product of the features and the learned projection divided by the normalized dot product.</p> class</span> ImageEncoder</span>(</span>nn</span>.</span>Module</span>):</span></span> def</span> __init__</span>(</span>self</span>,</span> width</span>,</span> img_size</span>,</span> patch_size</span>,</span> n_channels</span>,</span> n_layers</span>,</span> n_heads</span>,</span> emb_dim</span>):</span></span> super</span>().</span>__init__</span>()</span></span> </span> assert</span> img_size</span>[</span>0</span>]</span> %</span> patch_size</span>[</span>0</span>]</span> ==</span> 0</span> and</span> img_size</span>[</span>1</span>]</span> %</span> patch_size</span>[</span>1</span>]</span> ==</span> 0</span>, "</span>img_size dimensions must be divisible by patch_size dimensions</span>"</span></span> assert</span> width</span> %</span> n_heads</span> ==</span> 0</span>, "</span>width must be divisible by n_heads</span>"</span></span> </span> self</span>.</span>n_patches</span> =</span> (</span>img_size</span>[</span>0</span>]</span> </span> img_size</span>[</span>1</span>])</span> //</span> (</span>patch_size</span>[</span>0</span>]</span> </span> patch_size</span>[</span>1</span>])</span></span> </span> self</span>.</span>max_seq_length</span> =</span> self</span>.</span>n_patches</span> +</span> 1</span></span> </span> # Patch Embedding</span></span> self</span>.</span>linear_project</span> =</span> nn</span>.</span>Conv2d</span>(</span>n_channels</span>,</span> width</span>,</span> kernel_size</span>=</span>patch_size</span>,</span> stride</span>=</span>patch_size</span>)</span></span> </span> # Classification Token</span></span> self</span>.</span>cls_token</span> =</span> nn</span>.</span>Parameter</span>(</span>torch</span>.</span>randn</span>(</span>1</span>,</span> 1</span>,</span> width</span>))</span></span> </span> self</span>.</span>positional_embedding</span> =</span> PositionalEmbedding</span>(</span>width</span>,</span>self</span>.</span>max_seq_length</span>)</span></span> </span> self</span>.</span>encoder</span> =</span> nn</span>.</span>ModuleList</span>([</span>TransformerEncoder</span>(</span>width</span>,</span>n_heads</span>)</span> for</span> _</span> in</span> range</span>(</span>n_layers</span>)])</span></span> </span> # learned proj of image to embed</span></span> self</span>.</span>projection</span> =</span> nn</span>.</span>Parameter</span>(</span>torch</span>.</span>randn</span>(</span>width</span>,</span> emb_dim</span>))</span></span> </span> </span> def</span> forward</span>(</span>self</span>,</span>x</span>):</span></span> # Patch Embedding</span></span> x</span> =</span> self</span>.</span>linear_project</span>(</span>x</span>)</span></span> x</span> =</span> x</span>.</span>flatten</span>(</span>2</span>).</span>transpose</span>(</span>1</span>,</span> 2</span>)</span></span> </span> # Positional Embedding</span></span> x</span> =</span> torch</span>.</span>cat</span>((</span>self</span>.</span>cls_token</span>.</span>expand</span>(</span>x</span>.</span>size</span>()[</span>0</span>],</span> -</span>1</span>,</span> -</span>1</span>),</span>x</span>),</span> dim</span>=</span>1</span>)</span></span> x</span> =</span> self</span>.</span>positional_embedding</span>(</span>x</span>)</span></span> </span> # Transformer Encoder</span></span> for</span> encoder_layer</span> in</span> self</span>.</span>encoder</span>:</span></span> x</span> =</span> encoder_layer</span>(</span>x</span>)</span></span> </span> # Takes Class Tokens</span></span> x</span> =</span> x</span>[:,</span> 0</span>, :]</span></span> </span> # joint multimodal embedding</span></span> if</span> self</span>.</span>projection</span> is not</span> None</span>:</span></span> x</span> =</span> x</span> @</span> self</span>.</span>projection</span></span> </span> x</span> =</span> x</span> /</span> torch</span>.</span>norm</span>(</span>x</span>,</span> dim</span>=-</span>1</span>,</span> keepdim</span>=</span>True</span>)</span></span> </span> return</span> x</span></span></code></pre>Training</h3> </p> The training process consists of providing image, caption pairs from the dataset. CLIP uses contrastive loss to train the model. Since we are looking to maximize the scaled pairwise cosine similarities between the image and text embeddings along the diagonal where the text and image embeddings are correctly paired, we can use cross entropy loss across the rows and columns with psuedo-labels corresponding to the index of the embedding. This is the same as evaluating $n$ distinct text -> image estimates and $n$ image -> text estimates concurrently. The model loss is the mean loss between the text and image cross entropy loss.</p> labels</span> =</span> torch</span>.</span>arange</span>(</span>logits</span>.</span>shape</span>[</span>0</span>]).</span>to</span>(</span>self</span>.</span>device</span>)</span></span> # Label for row/column i is i (i.e. the index of the correct other half of the pair)</span></span> </span> loss_i</span> =</span> nn</span>.</span>functional</span>.</span>cross_entropy</span>(</span>logits</span>.</span>transpose</span>(</span>-</span>2</span>,</span>-</span>1</span>),</span> labels</span>)</span></span> loss_t</span> =</span> nn</span>.</span>functional</span>.</span>cross_entropy</span>(</span>logits</span>,</span> labels</span>)</span></span> </span> loss</span> =</span> (</span>loss_i</span> +</span> loss_t</span>)</span> /</span> 2</span></span></code></pre>Dataset</h3> For this tutorial we will use Faith Aykon</a>'s Mini-Pokemon dataset</a>, hosted on HuggingFace (this requires datasets==2.21.0</code>).</p> This dataset consists of 280 examples in a 210/70 train/test split. The full dataset has 7000 images but as such takes much longer to train, though the code can be trivially modified to use the full dataset</p> We will perform a number of modifications to this dataset to make it more suitable to training for CLIP.</p> from</span> torchvision</span>.</span>transforms</span> import</span> v2</span></span> class</span> Pokemon</span>(</span>Dataset</span>):</span></span> def</span> __init__</span>(</span>self</span>,</span> train</span>=</span>True</span>):</span></span> </span> # Download the dataset from HuggingFace, use the mini split (change "mini" to "full" for the full dataset)</span></span> self</span>.</span>dataset</span> =</span> load_dataset</span>("</span>fcakyon/pokemon-classification</span>", "</span>mini</span>",</span> trust_remote_code</span>=</span>True</span>)</span></span> </span> # Image preprocessing</span></span> self</span>.</span>transform</span> =</span> v2</span>.</span>Compose</span>([</span></span> v2</span>.</span>Resize</span>((</span>128</span>,</span> 128</span>)),</span></span> v2</span>.</span>ToTensor</span>()</span></span> ])</span></span> </span> if</span> train</span>:</span></span> self</span>.</span>split</span> =</span> "</span>train</span>"</span></span> else</span>:</span></span> self</span>.</span>split</span> =</span> "</span>test</span>"</span></span> </span> </span> self</span>.</span>label_names</span> =</span> self</span>.</span>dataset</span>[</span>self</span>.</span>split</span>].</span>features</span>["</span>labels</span>"].</span>names</span></span> </span> self</span>.</span>caption_options</span> =</span> ["</span>An image of </span>{0}</span>",</span></span> "</span>A </span>{0}</span>",</span></span> "</span>A photo of </span>{0}</span>",</span></span> "</span>A </span>{0}</span> in a photo</span>",</span></span> "</span>A picture of </span>{0}</span>",</span></span> "</span>A </span>{0}</span> image</span>"]</span></span> </span> self</span>.</span>captions</span> =</span> {</span></span> i</span>:</span> f</span>"An image of a </span>{</span>l</span>}</span>"</span> for</span> i</span>,</span> l</span> in</span> enumerate</span>(</span>self</span>.</span>label_names</span>)</span></span> }</span></span> self</span>.</span>labels</span> =</span> {</span></span> i</span> :</span> l</span> for</span> i</span>,</span>l</span> in</span> enumerate</span>(</span>self</span>.</span>label_names</span>)</span></span> }</span></span> </span> def</span> __len__</span>(</span>self</span>):</span></span> return</span> self</span>.</span>dataset</span>.</span>num_rows</span>[</span>self</span>.</span>split</span>]</span></span> </span> def</span> __getitem__</span>(</span>self</span>,</span>i</span>):</span></span> img</span> =</span> self</span>.</span>dataset</span>[</span>self</span>.</span>split</span>][</span>i</span>]["</span>image</span>"]</span></span> img</span> =</span> self</span>.</span>transform</span>(</span>img</span>)</span></span> </span> caption_template</span> =</span> np</span>.</span>random</span>.</span>choice</span>(</span>self</span>.</span>caption_options</span>)</span></span> caption_text</span> =</span> caption_template</span>.</span>format</span>(</span>self</span>.</span>labels</span>[</span>self</span>.</span>dataset</span>[</span>self</span>.</span>split</span>][</span>i</span>]["</span>labels</span>"]])</span></span> cap</span>,</span> mask</span> =</span> tokenizer</span>(</span>caption_text</span>)</span></span> </span> mask</span> =</span> mask</span>.</span>repeat</span>(</span>len</span>(</span>mask</span>),</span>1</span>)</span></span> </span> return</span> {"</span>image</span>":</span> img</span>, "</span>caption</span>":</span> cap</span>, "</span>mask</span>":</span> mask</span>, "</span>text</span>":</span> caption_text</span>, "</span>label</span>":</span> self</span>.</span>dataset</span>[</span>self</span>.</span>split</span>][</span>i</span>]["</span>labels</span>"]}</span></span></code></pre>Image Preprocessing</h4> We define a transformation pipeline which gets applied to each image using</p> self</span>.</span>transform</span> =</span> v2</span>.</span>Compose</span>([</span></span> v2</span>.</span>Resize</span>((</span>128</span>,</span> 128</span>)),</span></span> v2</span>.</span>ToTensor</span>()</span></span> ])</span></span></code></pre> There is not too much data augmentation needed for simple cases, therefore we just resize the input image to a reasonable size.</p> Text Preprocessing</h4> The original dataset is set up for more traditional classification approaches, i.e. some class label for each image which is an int</code> representing the index of the 1 in a one-hot encoded form of the label. Since CLIP uses text and not one-hot encoded vectors for the “labels”, we need to generate them. The critical information is the type of Pokemon in the image. However, there are many ways in natural language to convey the same information and we want to be robust to phrasing as it will help our classifier be more robust later on.</p> Therefore, we include a number of caption templates that phrase the label in many semantically similar ways. When retrieving a new image, a label pair is pulled from the dataset, this code will choose one of the caption templates to create a caption containing the label text.</p> class</span> Pokemon</span>():</span></span> def</span> __init</span>(</span>self</span>,</span> ...</span>):</span></span> ...</span></span> self</span>.</span>caption_options</span> =</span> ["</span>An image of </span>{0}</span>",</span></span> "</span>A </span>{0}</span>",</span></span> "</span>A photo of </span>{0}</span>",</span></span> "</span>A </span>{0}</span> in a photo</span>",</span></span> "</span>A picture of </span>{0}</span>",</span></span> "</span>A </span>{0}</span> image</span>"]</span></span> </span> def</span> __getitem__</span>(</span>self</span>,</span> i</span>):</span></span> ...</span></span> caption_template</span> =</span> rng</span>.</span>choice</span>(</span>self</span>.</span>caption_options</span>)</span></span> caption_text</span> =</span> caption_template</span>.</span>format</span>(</span>self</span>.</span>labels</span>[</span>self</span>.</span>dataset</span>[</span>self</span>.</span>split</span>][</span>i</span>]["</span>labels</span>"]])</span></span> </span></code></pre>Tokenization</h4> </p> Transformer models do not work directly on text, instead they use a numerical representation of characters (tokens). In this example we use a trivial tokenization scheme UTF-8.</p> With the UTF-8 encoding the max vocabulary size is 256 since we are direct mapping from characters. For larger desired context sizes, other tokenization schemes with greater vocabulary sizes may be desired.</p> The tokenizer delimits the input string with start and end tokens, reserved values that denote the limits of the input. Since the input to the transformer is fixed size, the input tensor is padded to the full width of the input. Finally a mask is created to denote that padded inputs should be ignored.</p> def</span> tokenizer</span>(</span>text</span>,</span> encode</span>=</span>True</span>,</span> mask</span>=</span>None</span>,</span> max_seq_length</span>=</span>32</span>):</span></span> if</span> encode</span>:</span></span> out</span> =</span> chr</span>(</span>2</span>)</span> +</span> text</span> +</span> chr</span>(</span>3</span>)</span> # Adding SOT and EOT tokens</span></span> out</span> =</span> out</span> +</span> "".</span>join</span>([</span>chr</span>(</span>0</span>)</span> for</span> _</span> in</span> range</span>(</span>max_seq_length</span>-</span>len</span>(</span>out</span>))])</span> # Adding Padding</span></span> out</span> =</span> torch</span>.</span>IntTensor</span>(</span>list</span>(</span>out</span>.</span>encode</span>("</span>utf-8</span>")))</span> # Encoding Text</span></span> mask</span> =</span> torch</span>.</span>ones</span>(</span>len</span>(</span>out</span>.</span>nonzero</span>()))</span></span> mask</span> =</span> torch</span>.</span>cat</span>((</span>mask</span>,</span>torch</span>.</span>zeros</span>(</span>max_seq_length</span>-</span>len</span>(</span>mask</span>)))).</span>type</span>(</span>torch</span>.</span>IntTensor</span>)</span></span> else</span>:</span></span> out</span> =</span> [</span>chr</span>(</span>x</span>)</span> for</span> x</span> in</span> text</span>[</span>1</span>:</span>len</span>(</span>mask</span>.</span>nonzero</span>())</span>-</span>1</span>]]</span></span> out</span> =</span> "".</span>join</span>(</span>out</span>)</span></span> mask</span> =</span> None</span></span> </span> return</span> out</span>,</span> mask</span></span></code></pre> These tokenzied forms of the captions are pre-calculated as part of the dataset.</p> cap</span>,</span> mask</span> =</span> tokenizer</span>(</span>caption_text</span>)</span></span></code></pre> Since the mask will be applied to the attention scores ($max_seq_len x max_seq_len$), it needs to be repeated to be applied to each row.</p> mask</span> =</span> mask</span>.</span>repeat</span>(</span>len</span>(</span>mask</span>),</span>1</span>)</span></span></code></pre> Therefore for each entry in the dataset we have the following information</p> {"</span>image</span>":</span> img</span>, "</span>caption</span>":</span> cap</span>, "</span>mask</span>":</span> mask</span>, "</span>text</span>":</span> caption_text</span>, "</span>label</span>":</span> self</span>.</span>dataset</span>[</span>self</span>.</span>split</span>][</span>i</span>]["</span>labels</span>"]}</span></span></code></pre>Example</h5> </p> image</span>.</span>shape</span>:</span> torch</span>.</span>Size</span>([</span>3</span>,</span> 128</span>,</span> 128</span>])</span></span> caption</span>.</span>shape</span>:</span> torch</span>.</span>Size</span>([</span>32</span>])</span></span> mask</span>.</span>shape</span>:</span> torch</span>.</span>Size</span>([</span>32</span>,</span> 32</span>])</span></span> text</span>: "</span>A Alakazam image</span>"</span></span> caption</span>(</span>tokenized</span>):</span> tensor</span>([</span> 2</span>,</span> 65</span>,</span> 32</span>,</span> 112</span>,</span> 104</span>,</span> 111</span>,</span> 116</span>,</span> 111</span>,</span> 32</span>,</span> 111</span>,</span> 102</span>,</span> 32</span>,</span> 65</span>,</span> 108</span>,</span></span> 97</span>,</span> 107</span>,</span> 97</span>,</span> 122</span>,</span> 97</span>,</span> 109</span>,</span> 3</span>,</span> 0</span>,</span> 0</span>,</span> 0</span>,</span> 0</span>,</span> 0</span>,</span> 0</span>,</span> 0</span>,</span></span> 0</span>,</span> 0</span>,</span> 0</span>,</span> 0</span>],</span> dtype</span>=</span>torch</span>.</span>int32</span>)</span></span> mask</span>:</span> tensor</span>([[</span>1</span>,</span> 1</span>,</span> 1</span>,</span> …</span>,</span> 0</span>,</span> 0</span>,</span> 0</span>],</span></span> [</span>1</span>,</span> 1</span>,</span> 1</span>,</span> …</span>,</span> 0</span>,</span> 0</span>,</span> 0</span>],</span></span> [</span>1</span>,</span> 1</span>,</span> 1</span>,</span> …</span>,</span> 0</span>,</span> 0</span>,</span> 0</span>],</span></span> …</span>,</span></span> [</span>1</span>,</span> 1</span>,</span> 1</span>,</span> …</span>,</span> 0</span>,</span> 0</span>,</span> 0</span>],</span></span> [</span>1</span>,</span> 1</span>,</span> 1</span>,</span> …</span>,</span> 0</span>,</span> 0</span>,</span> 0</span>],</span></span> [</span>1</span>,</span> 1</span>,</span> 1</span>,</span> …</span>,</span> 0</span>,</span> 0</span>,</span> 0</span>]],</span> dtype</span>=</span>torch</span>.</span>int32</span>)</span></span></code></pre>Hyperparameters</h4> These are the parameters I used for training on a 3080Ti. The notebook contains these parameters and the seed I used. Some modifications to the batch size might be needed if training on smaller GPUs.</p> emb_dim</span> =</span> 32</span></span> vit_width</span> =</span> 9</span></span> img_size</span> =</span> (</span>128</span>,</span>128</span>)</span></span> patch_size</span> =</span> (</span>64</span>,</span>64</span>)</span></span> n_channels</span> =</span> 3</span></span> vit_layers</span> =</span> 3</span></span> vit_heads</span> =</span> 3</span></span> vocab_size</span> =</span> 256</span></span> text_width</span> =</span> 32</span></span> max_seq_length</span> =</span> 32</span></span> text_heads</span> =</span> 8</span></span> text_layers</span> =</span> 4</span></span> lr</span> =</span> 1e-3</span></span> epochs</span> =</span> 1500</span></span> batch_size</span> =</span> 1024</span></span></code></pre>Training Loop</h4> device</span> =</span> torch</span>.</span>device</span>("</span>cuda</span>"</span> if</span> torch</span>.</span>cuda</span>.</span>is_available</span>()</span> else</span> "</span>cpu</span>")</span></span> print</span>("</span>Using device: </span>",</span> device</span>,</span> f</span>"(</span>{</span>torch</span>.</span>cuda</span>.</span>get_device_name</span>(</span>device</span>)</span>}</span>)"</span> if</span> torch</span>.</span>cuda</span>.</span>is_available</span>()</span> else</span> "")</span></span> </span> model</span> =</span> CLIP</span>(</span>emb_dim</span>,</span> vit_width</span>,</span> img_size</span>,</span> patch_size</span>,</span> n_channels</span>,</span> vit_layers</span>,</span> vit_heads</span>,</span> vocab_size</span>,</span> text_width</span>,</span> max_seq_length</span>,</span> text_heads</span>,</span> text_layers</span>).</span>to</span>(</span>device</span>)</span></span> </span> optimizer</span> =</span> optim</span>.</span>Adam</span>(</span>model</span>.</span>parameters</span>(),</span> lr</span>=</span>lr</span>)</span></span> </span> best_loss</span> =</span> np</span>.</span>inf</span></span> for</span> epoch</span> in</span> range</span>(</span>epochs</span>):</span></span> for</span> i</span>,</span> data</span> in</span> enumerate</span>(</span>train_loader</span>,</span> 0</span>):</span></span> img</span>,</span> cap</span>,</span> mask</span> =</span> data</span>["</span>image</span>"].</span>to</span>(</span>device</span>),</span> data</span>["</span>caption</span>"].</span>to</span>(</span>device</span>),</span> data</span>["</span>mask</span>"].</span>to</span>(</span>device</span>)</span></span> loss</span> =</span> model</span>(</span>img</span>,</span>cap</span>,</span>mask</span>)</span></span> optimizer</span>.</span>zero_grad</span>()</span></span> loss</span>.</span>backward</span>()</span></span> optimizer</span>.</span>step</span>()</span></span> </span> # Saves model if it performed better than the previous best</span></span> print</span>(</span>f</span>"Epoch [</span>{</span>epoch</span>+</span>1}</span>/</span>{</span>epochs</span>}</span>], Batch Loss: </span>{</span>loss</span>.</span>item</span>()</span>:.3f</span>}</span>"</span>)</span></span> if</span> loss</span>.</span>item</span>()</span> <=</span> best_loss</span>:</span></span> best_loss</span> =</span> loss</span>.</span>item</span>()</span></span> torch</span>.</span>save</span>(</span>model</span>.</span>state_dict</span>(), "</span>clip_pokemon4.pt</span>")</span></span> print</span>("</span>Model Saved.</span>")</span></span></code></pre>Testing Performance</h3> </p> We can evaluate how well our model is at associating image text pairs. We start by creating a spanning set of captions for the different possible labels using one a slightly different caption form from those seen in training (ex. ”An image of a Pikachu”). This was actually done as part of the dataset construction:</p> self</span>.</span>captions</span> =</span> {</span></span> i</span>:</span> f</span>"An image of a </span>{</span>l</span>}</span>"</span> for</span> i</span>,</span> l</span> in</span> enumerate</span>(</span>self</span>.</span>label_names</span>)</span></span> }</span></span></code></pre> Each of these potential captions is tokenzied using the tokenizer and fed to the text encoder and a batch of images from the test set are fed into the image encoder.</p> We then calculate the cosine similarity between the text and image embeddings and run softmax to get probabilities that any particular label is the best pairing for a particular image.</p> We can then match these predicted captions with the true label to determine if the model was correct or not.</p> # Loading Best Model</span></span> model</span> =</span> CLIP</span>(</span>emb_dim</span>,</span> vit_width</span>,</span> img_size</span>,</span> patch_size</span>,</span> n_channels</span>,</span> vit_layers</span>,</span> vit_heads</span>,</span> vocab_size</span>,</span> text_width</span>,</span> max_seq_length</span>,</span> text_heads</span>,</span> text_layers</span>).</span>to</span>(</span>device</span>)</span></span> model</span>.</span>load_state_dict</span>(</span>torch</span>.</span>load</span>("</span>clip_pokemon4.pt</span>",</span> map_location</span>=</span>device</span>))</span></span> </span> # Getting dataset captions to compare images to</span></span> text</span> =</span> torch</span>.</span>stack</span>([</span>tokenizer</span>(</span>x</span>)[</span>0</span>]</span> for</span> x</span> in</span> test_set</span>.</span>captions</span>.</span>values</span>()]).</span>to</span>(</span>device</span>)</span></span> mask</span> =</span> torch</span>.</span>stack</span>([</span>tokenizer</span>(</span>x</span>)[</span>1</span>]</span> for</span> x</span> in</span> test_set</span>.</span>captions</span>.</span>values</span>()])</span></span> mask</span> =</span> mask</span>.</span>repeat</span>(</span>1</span>,</span>len</span>(</span>mask</span>[</span>0</span>])).</span>reshape</span>(</span>len</span>(</span>mask</span>),</span>len</span>(</span>mask</span>[</span>0</span>]),</span>len</span>(</span>mask</span>[</span>0</span>])).</span>to</span>(</span>device</span>)</span></span> </span> correct</span>,</span> total</span> =</span> 0</span>,</span>0</span></span> with</span> torch</span>.</span>no_grad</span>():</span></span> for</span> data</span> in</span> test_loader</span>:</span></span> images</span>,</span> labels</span> =</span> data</span>["</span>image</span>"].</span>to</span>(</span>device</span>),</span> data</span>["</span>label</span>"].</span>to</span>(</span>device</span>)</span></span> image_features</span> =</span> model</span>.</span>image_encoder</span>(</span>images</span>)</span></span> text_features</span> =</span> model</span>.</span>text_encoder</span>(</span>text</span>,</span> mask</span>=</span>mask</span>)</span></span> </span> image_features</span> /=</span> image_features</span>.</span>norm</span>(</span>dim</span>=-</span>1</span>,</span> keepdim</span>=</span>True</span>)</span></span> text_features</span> /=</span> text_features</span>.</span>norm</span>(</span>dim</span>=-</span>1</span>,</span> keepdim</span>=</span>True</span>)</span></span> similarity</span> =</span> (</span>100.0</span> </span> (</span>image_features</span> @</span> text_features</span>.</span>T</span>)).</span>softmax</span>(</span>dim</span>=-</span>1</span>)</span></span> _</span>,</span> indices</span> =</span> torch</span>.</span>max</span>(</span>similarity</span>,</span>1</span>)</span></span> </span> correct</span> +=</span> torch</span>.</span>sum</span>(</span>indices</span>==</span>labels</span>)</span></span> total</span> +=</span> len</span>(</span>labels</span>)</span></span> </span> print</span>(</span>f</span>'</span>\n</span>Model Accuracy: </span>{100</span> </span> correct</span> //</span> total</span>}</span> %'</span>)</span></span></code></pre> Using my training settings and seed, I was able to achieve 87% accuracy on the Pokemon-mini dataset. This is not really representative for C LIP’s power, as the dataset we have used for training here is very small. Using a CNN would actually be the preferred approach here. Yet, for very large datasets CLIP has outperformed previous CNN model.</p> Zero-shot Classification</h3> </p> We can reuse our CLIP model to perform the classification task now. First we generate a list of possible labels. These will just be names of different types of Pokemon found in the dataset (ex. ”Pikachu”). We then tokenize each potential label and feed them to the text encoder. We also feed an unlabeled image to the image label. The CLIP model will return the similarities between each potential label and the image based on the training it had seen before. Note that we never just provide the label alone as a text pairing during training, but we do provide various different captions which all share the label word within them. This demonstrates how, because of our pre-training, we are robust to unseen label forms and yet can correctly associate the image with the correct label.</p> # Loading Best Model</span></span> model</span> =</span> CLIP</span>(</span>emb_dim</span>,</span> vit_width</span>,</span> img_size</span>,</span> patch_size</span>,</span> n_channels</span>,</span> vit_layers</span>,</span> vit_heads</span>,</span> vocab_size</span>,</span> text_width</span>,</span> max_seq_length</span>,</span> text_heads</span>,</span> text_layers</span>).</span>to</span>(</span>device</span>)</span></span> model</span>.</span>load_state_dict</span>(</span>torch</span>.</span>load</span>("</span>clip_pokemon4.pt</span>",</span> map_location</span>=</span>device</span>))</span></span> </span> </span> # Captions to compare images to</span></span> class_names</span> =</span> test_set</span>.</span>label_names</span></span> class_text</span> =</span> [</span>f</span>"</span>{</span>l</span>}</span>"</span> for</span> l</span> in</span> class_names</span>]</span></span> </span> text</span> =</span> torch</span>.</span>stack</span>([</span>tokenizer</span>(</span>x</span>)[</span>0</span>]</span> for</span> x</span> in</span> class_text</span>]).</span>to</span>(</span>device</span>)</span></span> mask</span> =</span> torch</span>.</span>stack</span>([</span>tokenizer</span>(</span>x</span>)[</span>1</span>]</span> for</span> x</span> in</span> class_text</span>])</span></span> mask</span> =</span> mask</span>.</span>repeat</span>(</span>1</span>,</span>len</span>(</span>mask</span>[</span>0</span>])).</span>reshape</span>(</span>len</span>(</span>mask</span>),</span>len</span>(</span>mask</span>[</span>0</span>]),</span>len</span>(</span>mask</span>[</span>0</span>])).</span>to</span>(</span>device</span>)</span></span> </span> idx</span> =</span> 12</span></span> </span> img</span> =</span> test_set</span>[</span>idx</span>]["</span>image</span>"][</span>None</span>,:]</span></span> plt</span>.</span>imshow</span>(</span> img</span>[</span>0</span>].</span>permute</span>(</span>1</span>,</span> 2</span>,</span> 0</span>),)</span></span> plt</span>.</span>title</span>(</span>test_set</span>[</span>idx</span>]["</span>text</span>"])</span></span> plt</span>.</span>show</span>()</span></span> img</span> =</span> img</span>.</span>to</span>(</span>device</span>)</span></span> with</span> torch</span>.</span>no_grad</span>():</span></span> image_features</span> =</span> model</span>.</span>image_encoder</span>(</span>img</span>)</span></span> text_features</span> =</span> model</span>.</span>text_encoder</span>(</span>text</span>,</span> mask</span>=</span>mask</span>)</span></span> </span> </span> image_features</span> /=</span> image_features</span>.</span>norm</span>(</span>dim</span>=-</span>1</span>,</span> keepdim</span>=</span>True</span>)</span></span> text_features</span> /=</span> text_features</span>.</span>norm</span>(</span>dim</span>=-</span>1</span>,</span> keepdim</span>=</span>True</span>)</span></span> similarity</span> =</span> (</span>100.0</span> </span> image_features</span> @</span> text_features</span>.</span>T</span>).</span>softmax</span>(</span>dim</span>=-</span>1</span>)</span></span> values</span>,</span> indices</span> =</span> similarity</span>[</span>0</span>].</span>topk</span>(</span>5</span>)</span></span> </span> # Print the result</span></span> print</span>("</span>\n</span>Top predictions:</span>\n</span>")</span></span> for</span> value</span>,</span> index</span> in</span> zip</span>(</span>values</span>,</span> indices</span>):</span></span> print</span>(</span>f</span>"</span>{</span>class_names</span>[</span>int</span>(</span>index</span>)]</span>:>16s</span>}</span>: </span>{100</span> </span> value</span>.</span>item</span>()</span>:.2f</span>}</span>%"</span>)</span></span></code></pre> You can find a notebook with the code from this tutorial here</a></p> All Recommendation Engines Should Follow Twitter's Example on Transparency Unknown — Sat, 01 Apr 2023 00:00:00 +0000 This week has been weird to say the least. We have fringe figures in the artificial intelligence community publishing opinions in Time Magazine on the need to take violent action to stop the propagation of large language models</a>, but I thought the most important story was Elon Musk and Twitter releasing the source code for their Tweet recommendation system</a>.</p> I'm going to keep referring to this thing as a system or engine. I refuse to call it an algorithm. There are no strong guarantees associated with these systems, they mostly boil down to a collection of heuristics. Calling them an algorithm bastardizes the meaning of the term. </details> There's a lot of reasons to be tired of hearing about Twitter and Elon Musk. Twitter is a navel-gazy self important subculture full of "niche internet celebrities" being toxic to each other in one way or another. And Elon oscillates from being out of touch to down right unhinged depending on the hour. However, Twitter and other social media platforms for many, and particularly many who occupy other places of influence in society, serves as their primary lens on the state of the world. Many measure importance of issues, people, ideas etc. based on the traction they garner on these platforms. Therefore, it matters how and why some things are widely promoted and somethings are suppressed.</p> When Twitter released the source, Elon put out the following Tweet.</p> Most of the recommendation algorithm will be made open source today. The rest will follow. Acid test is that independent third parties should be able to determine, with reasonable accuracy, what will probably be shown to users. No doubt, many embarrassing issues will be… https://t.co/41U4oexIev</a></p>— Elon Musk (@elonmusk) March 31, 2023</a></blockquote>

Do We Still Need Agile?

Unknown — Sat, 11 Apr 2026 00:00:00 +0000

Agile</a> was invented to solve a specific problem: software development was slow, expensive, and wrong. The waterfall process — full requirements, full design, full implementation, then test and discover you built the wrong thing — routinely produced systems that were over budget, late, and didn't match what users actually needed. The Agile Manifesto</a> in 2001 was a corrective: working software over comprehensive documentation, responding to change over following a plan, customer collaboration over contract negotiation. The core insight was that you could not know what was right in advance, so the process should be optimized for learning fast and adapting constantly.

That insight was correct, for its time. But the underlying assumption — that implementation is expensive and slow, so you must minimize rework by keeping cycles tight — is being aggressively eroded by AI-assisted development. Which raises a question: if the cost of implementation is approaching zero, does the logic of Agile still hold? And if it doesn't — what replaces it?

To understand what we might be giving up, it's worth remembering what Agile replaced and why.

Waterfall</a> was not invented by sadists. It came from Winston Royce's 1970 paper</a> on managing large software projects, and it reflected how large engineering projects actually worked: you designed the bridge fully before you started pouring concrete, because once you started pouring you could not cheaply change the design. Software seemed to follow the same logic. The BDUF</a> — Big Design Up Front — tradition was not irrational. If implementation takes months and you can only do it once, you had better be sure about what you're implementing.

The problem was that software is not concrete. Requirements change. Users don't know what they want until they see what they don't want. The feedback loops in waterfall were months or years long, which meant you could spend enormous effort building something entirely wrong.

Extreme Programming</a>, Scrum</a>, Kanban</a> — these were all attempts to shorten those feedback loops by treating implementation as cheap and repeatable. Write the test before the code. Ship every two weeks. Keep the backlog small and reprioritize constantly. The ritual of the sprint exists specifically because someone calculated that two weeks was short enough to catch mistakes before they became catastrophic.

But "short enough" was a function of how long implementation actually took.

Here is the shift. Agile's unit of work was always calibrated to implementation cost. One sprint equals two weeks equals roughly one feature, or one meaningful slice of a feature. That ratio was not arbitrary — it was set by how long implementation actually took. The sprint length, the story point system, the definition of "done," the shape of the backlog: all of it was tuned to a world where a feature cost a week of engineering time.

With AI-assisted development, that ratio has broken. A competent engineer can now implement in an afternoon what used to take a sprint. Which means the unit of work per sprint is no longer one feature — it is closer to a full product version. A prototype that used to require a sprint can be standing up the same afternoon. An MVP that used to require a quarter can exist by the end of the week.

Agile does not scale to this. The ceremonies — sprint planning, backlog grooming, story points, velocity tracking — were designed to manage the flow of work when work moved slowly. When work moves fast enough that you could ship a full product version before the sprint planning meeting is over, the management overhead of Agile is no longer a small fraction of the work. It is the work. You spend more time in the process ritual than doing the thing the process was supposed to organize.

The constraint has moved. It is no longer "how do we avoid wasting implementation effort." It becomes "how do we make sure we are building the right thing at all."

This is, ironically, the exact problem that BDUF was designed to solve.

The older methodologies that Agile displaced — waterfall, RUP</a>, spiral development</a> — had long design phases not because they were bureaucratic for its own sake, but because design was cheaper than implementation. Thinking was cheaper than building. You could iterate through many possible designs on paper — or in diagrams, or in formal specifications — at a fraction of the cost of implementing each one.

Spiral development in particular is worth revisiting. Barry Boehm</a> proposed it in 1986 as an iterative process that put risk analysis at the center of each cycle: identify the biggest risks, build a prototype to resolve those risks, evaluate, then plan the next spiral. It was explicitly not "design everything upfront" — it was "resolve the hardest unknowns first, repeatedly, before committing to full implementation." That is a remarkably sane framework, and it got abandoned because the prototypes and evaluations still took a long time.

What if they didn't anymore? What if an afternoon of work with AI could resolve the risk that used to require a two-week spike?

The specific problem with Kanban</a> and Agile in a world of cheap implementation is that they are optimized for reactivity — responding to new information quickly. But reactivity is only valuable relative to how long reactions used to take. Kanban's pull system, Scrum's sprint cadence, the constant backlog reprioritization — these were designed for a world where the cost of a wrong decision was measured in weeks of engineering time, and the best you could do was catch it at the next sprint review.

If you can just try the thing in an afternoon, you already have faster feedback than any sprint ceremony provides. The overhead of managing the process — standups, planning, grooming, retrospectives, velocity tracking — was justified when it was a small fraction of total engineering time. When a full product version fits in a sprint, it is no longer a small fraction. The process overhead dominates.

Kanban in particular assumes a steady flow of discrete work items of roughly consistent size moving through defined stages. That model made sense when the unit of work was a feature or a task. It breaks when the unit of work is a product version — because you can't pull a "full product version" off a board and have it flow through QA in the same way a bug fix does. The work items are not consistent anymore. Some are hours, some are a day, some are a full product. The pipeline model does not fit.

There is also a subtler issue. Kanban and Agile were explicitly designed to keep teams in a state of perpetual reaction: what does the customer need right now, what is blocking us right now, what did we learn last sprint. This is the right posture when implementation is slow and costly. But it systematically underweights long-horizon thinking. When you are always reacting, you are rarely designing. The backlog replaces the architecture. The sprint replaces the vision. You end up with software that works for the next two weeks but has no coherent shape.

This was always a critique of Agile — that it produced working software that was difficult to evolve</a> because nobody had ever sat down to think about it whole. AI-assisted implementation makes this worse, not better, because it lowers the cost of adding features without lowering the cost of having no coherent architecture.

So what might a better methodology look like in a world of cheap implementation?

A few hypotheses:

Longer design phases, shorter implementation phases. If implementation is fast, the bottleneck is knowing what to build. Invest more time in the design phase — not BDUF in the sense of specifying every detail upfront, but genuine exploratory design: competing approaches, user research, prototype evaluation, architectural thinking. Then implement quickly once you know what you're doing.

Multiple competing prototypes. If building a prototype costs an afternoon instead of a sprint, you can build three and compare them. This is standard practice in hardware design and industrial design — it was prohibitively expensive in software. It may not be anymore. Design sprints</a> pointed in this direction but were still constrained by implementation cost.

Risk-first sequencing à la Boehm. Before committing to an implementation direction, explicitly identify the riskiest assumptions — the things that would invalidate the design if they turned out to be wrong — and resolve those first. With cheap implementation, you can spike each risk quickly.

Less ceremony, more thinking. The standups, story points, and sprint planning were process overhead justified by the need to coordinate expensive implementation work. If implementation is cheap and fast, the coordination overhead may not be worth it. A smaller team with a clearer shared vision and a longer planning horizon may outperform a larger Agile team running process for its own sake.

None of this means Agile is simply wrong. The core values — working software over documentation, customer collaboration, responding to change — remain sound. But the practices that were derived from those values assumed a world where implementation was the expensive constraint. That world is changing faster than the practices are.

The irony is that we may be heading back toward something that looks more like the methodologies Agile displaced — not because those methodologies were right all along, but because the conditions that made them wrong are being removed. Waterfall failed because feedback loops were too slow. AI is compressing those loops. The question is whether we are thoughtful enough about which loops to compress, and whether we preserve the parts of the process that were not about speed at all — the parts about thinking clearly, designing coherently, and building something that will still make sense in two years.

The sprint was a workaround for expensive implementation. The workaround may be expiring. It's worth asking what we actually want to do with the time we're getting back.

Humanities in SV

Unknown — Fri, 10 Apr 2026 00:00:00 +0000

In 2024 Apple released an ad for the iPad Pro</a>. A hydraulic press slowly destroys a grand piano, paint cans, cameras, books, guitars, trumpets, record players — physical manifestations of human creative expression — as they are compressed into a thin slab of aluminum and glass. They intended to communicate that all you need is an iPad to access all these art forms, that the iPad was the ultimate window to access creativity.
However, people did not take the ad this way. Instead it became a symbol of a general discontent with technology. Instead of all these physical, specific, intentionally designed tools and mediums, we get a blank featureless slab that doesn't do anything particularly well and mostly turns into an endless consumption device. The backlash was severe enough that Apple issued a public apology. Hugh Grant</a> called it "the destruction of the human experience."</a> Apple pulled it from TV.
The company that set itself the goal of creating "the bicycle of the mind" has lost its way to the point where it now is putting out messaging visualizing how they crushed and compressed the human experience into a box. This is not just an Apple story. It is the story of Silicon Valley over the last three decades — a slow forgetting of what technology was originally for: not to shortcut human activity, but to empower humans to do things that had never been done, to build mediums that had never existed.
Many people love to throw the criticism that tech bros missed their humanities classes in college. But that misses the point. Reading Kant or Heidegger, or taking an art appreciation class — which most of these people have probably done — does not teach you what actually got lost. It is something more basic: the belief that the most valuable thing technology can do is not remove effort from existing activities, but enable entirely new ones. That the goal is not shortcutting the human, but empowering them. That efficiency is not the only axis worth optimizing on, and may not even be the important one.

There is a specific post-60s cultural cocktail that produced the best of early tech. Countercultural utopianism. New Age metaphysics. A real engagement with art, music, and literature. Stewart Brand</a> and the Whole Earth Catalog</a>. The Grateful Dead</a> as early adopters of the WELL</a>. John Perry Barlow's</a> Declaration of Independence of Cyberspace</a>, which reads as naive now but was animated by a genuine belief that the network could be a space for human liberation rather than corporate extraction and efficency gains.
Technology is a tool for expanding human capability and consciousness, not replacing it. And crucially — the act of using the tool was supposed to make you more of a person, not less of one. The destination and the journey were both the point. Apple under Steve Jobs centered itself in this philosophy. The Mac's proportional fonts came directly from a calligraphy class he auditied. His obsession with industrial design wasn't aesthetic vanity; it came from a belief that how an object feels in your hand is part of what it communicates. He described the computer as a "bicycle for the mind" — a tool that makes the human more powerful, not a substitute for the human. The metaphor is precise. A bicycle doesn't choose your destination or walk for you. It applies leverage to the effort you were going to spend anyway. Jobs cited a study he'd read as a child: scientists measured energy per unit of distance across animals, and the condor won — most efficient locomotion on Earth. The human, without tools, was mediocre by comparison. But put a human on a bicycle and they blow past the condor by a factor of three. The computer was that, for the mind — not intelligence replacing yours, but a multiplier on the intelligence you bring to it. The person still has to pedal. The person still navigates. The agency stays human; the reach extends.
More concretely, Jobs understood that some of the most interesting territory in tech was where technology met artistic production. The 1996 Charlie Rose interview with Jobs and John Lasseter</a> is worth watching in full. Charlie Rose asks the question you'd expect: does this make movies faster? Cheaper? Lasseter</a> reframes it completely.

"We don't look at it as a way to replace any of the creativity or any of the real art of film making. We look at it as these are just a great new expensive pencils. It's artists using these computers as though an artist at Disney uses a piece of paper and a pencil." </blockquote>
He then goes further. "It's a very common belief that when computers come into a new artistic medium, it's either less expensive, takes less time, or it's going to replace something. It reminds me a lot of when photography was invented — everybody thought that painting was going to get replaced." The computers aren't cheaper. They aren't faster. They're a different medium that lets you tell different stories.
Lasseter is describing a pattern that recurs with every new medium. The Roland TR-808</a> drum machine was a commercial failure when it launched in 1980 — it didn't sound like real drums — and was discontinued after two years. Then hip-hop and electronic music got hold of it, and the 808's synthetic kick became the sonic foundation of an entire half-century of popular music. MIDI</a> was supposed to make musicians obsolete; instead it gave composers direct access to the full palette of orchestral sound from a bedroom. Desktop publishing</a> — PageMaker, Quark, a laser printer — was going to destroy graphic design by letting anyone make a layout; instead it produced entirely new visual aesthetics and democratized a craft that had been locked behind expensive typesetting equipment. Digital audio workstations</a> and cheap recording interfaces collapsed the cost of a studio to near zero, and rather than flooding the world with garbage music, they enabled genres — lo-fi, vaporwave, bedroom pop — that could only have come from individuals making things alone at odd hours with inexpensive tools. Digital photography</a> was not real photography — no grain, no chemical process, no darkroom. Every time, the argument runs the same way: the new thing will either replace the old thing or cheapen it. Every time, the new thing becomes its own medium with its own masters, its own aesthetic vocabulary, and a body of work that could not have existed any other way. Jobs, who got into Pixar</a> initially because the technology "blew him away," lands in the same place after a decade alongside Lasseter: "all this technology really is just in the service of the storytelling. The computers don't do the animation — they do the drawing."
That distinction matters enormously. Pixar's technology — and ILM's</a> before it — was developed in service of a creative vision. The renderer existed because Lasseter had something he wanted to show that no existing medium could show. The technology was downstream of the art.
The proof of this is in the specific things Pixar chose to build. In Toy Story 4</a>, the cinematography team implemented split diopter shots</a> — a technique from live-action filmmaking where a split lens holds two subjects at very different distances in simultaneous sharp focus, used by De Palma</a>, Spielberg</a>, Gordon Willis</a>. In CG you have no optical physics forcing your hand. You could just render everything sharp. Pixar implemented split diopter shots on purpose, because they were thinking like filmmakers, not like computer scientists. They were asking: what does this scene need cinematographically?
The Good Dinosaur</a> did similarly demanding work on crowd and herd animation — not because the technology required it but because the story required convincing scale, mass, living ecosystems of creatures. The question was always what the scene needed, and the technology answered.
WETA FX today</a> still operates this way: Joe Letteri</a> and his team build tools because directors like James Cameron</a> have specific things they need to express. The tech doesn't drive the story; the story drives the tech.
GarageBand</a> is another example. When Jobs introduced it at Macworld 2004 with John Mayer on stage</a>, the demo was a musician using a tool to make music. Mayer</a> plugged in his guitar and played — but that was the demo, not the point. The point is that anyone with something musical in their head could now get it out. You didn't need to play. You could build loop by loop, note by note. What you needed was intent. The software removed the barrier between the idea and the listener — it did not remove the human with the idea.
This is what it looks like when technology is genuinely human-centered. The tool amplifies the human. It does not replace them. And the process — Mayer practicing, the Pixar animator studying light, the engineer and the artist arguing about what a scene needs — is not inefficiency to be removed. It is the work. It is what produces people who know what they're doing.
Silliwood</a> — the 90s portmanteau for the convergence of Silicon Valley and Hollywood — was a brief, mostly failed attempt to formalize this intersection. Most of those companies were, as Jobs put it, places that existed "so they can raise investment, but they never produced any products." Pixar was, in his view, the only enterprise where the meeting of Silicon Valley and Hollywood had actually produced something. The reason Pixar worked and Silliwood didn't is the same reason: Pixar had Lasseter, and Lasseter had something to say. The technology followed the vision, not the other way around.

Somewhere in the 2000s-2010s, this tradition died quietly.
The dominant culture of Silicon Valley stopped growing out of art. It grew out of B2B SaaS. The founding mythology shifted from "bicycles for the mind" to "growth hacking," "enterprise ARR," and "product-market fit." The countercultural aesthetic got replaced with the aesthetic of the McKinsey deck: clean sans-serif fonts, white space, and an earnest belief that every human problem was an optimization problem.
Part of what drove this shift was structural. Venture capital developed a playbook good at evaluating one kind of bet: a measurable improvement on something that already exists. X% faster, Y% cheaper, growth rate, annual recurring revenue. These are legible — you can model them, defend them in a partners meeting, show them to LPs. The kind of bet Lasseter represented is much harder: a new medium whose economics cannot be modeled because the audience does not yet exist, whose value will only be evident after years of making things in it. Jobs funded Pixar personally for nearly a decade before it produced anything — close to $60 million of his own money, in a company with no revenue and no proof of concept for the medium it was trying to build. That kind of patience, and that tolerance for illegible upside, is structurally incompatible with the incentives of a modern venture fund. What gets funded is what fits on a pitch deck: productivity gains, market size, churn reduction. New mediums don't fit on pitch decks. They require an investor to imagine something that doesn't exist yet and believe, without evidence, that people will want to inhabit it once it does. That takes a different kind of bravery — and the industry optimized it out.
There's a version of this story that keeps repeating in computing specifically. VisiCalc</a> — the first spreadsheet, 1979 — automated the work of bookkeepers and accountants who spent careers doing by hand what a computer could now do in seconds. Word processors eliminated the professional typist. CAD software</a> eliminated the draftsman. Desktop publishing eliminated the typesetter. Each time, the argument from the technology side was pure efficiency: the computer does this faster and cheaper, therefore the human who used to do it is no longer needed. And each time, that was partially true and wholly incomplete — because the people being displaced weren't just doing the mechanical task, they were holding craft knowledge, judgment, and aesthetic sensibility that the software could not encode. When you fire all the typesetters and let the marketing team do layout in PageMaker, you save money and you lose something harder to name.
More than aesthetics: the fundamental question changed. It used to be what does this enable a person to do and become? It became what friction does this remove? Technology stopped being an end — a thing worth engaging with because of what it does to you — and became purely a means. A pipe. The output is what matters; the human in the middle is a cost to be minimized.
This logic does not stay in enterprise software. It leaks into every consumer product built by the same culture. DoorDash</a>, Uber Eats</a>, Instacart</a> — the pitch is pure friction removal: food appears, you did not have to cook, you did not have to go anywhere, you did not have to talk to anyone. The convenience is real. But cooking is not just calorie acquisition. It is a skill, a ritual, a way of caring for people, a form of creativity with immediate sensory feedback. The process of going to a restaurant is social, spatial, cultural — you are somewhere, with someone, the meal is an event. What gets optimized away is not just effort. It is the texture of daily life, the practices through which people develop competence and connection. The app does not ask what cooking does for you. It asks how fast you want it gone.
The same logic governs attention. TikTok</a> removes the friction of choosing what to watch. The algorithm decides; content arrives; you never have to seek, discover, or exercise taste. But finding things — building a sense of what you like and why, following a thread of curiosity until you've learned something, being bored enough to go looking — is not inefficiency. It is how you develop taste. Instagram</a> removes the friction of staying in touch, and replaces actual connection with broadcast. The friction of calling someone, having a meal, being present — gone. What's also gone is intimacy. More broadly, social media removes the friction of boredom. Idle moments used to be spaces for thought, daydreaming, conversation. Now the phone fills them instantly. The space in which ideas form gets optimized away. The For You Page does not ask what watching does for you. It asks how long it can keep you there.
The trajectory of Nest</a> captures something sharper: the efficiency-first culture doesn't just produce this kind of product — it absorbs even companies that started elsewhere. Tony Fadell — who had led the iPod team at Apple — founded Nest in 2010 to build a thermostat. The original Nest Learning Thermostat</a> was a round, beautifully machined object with a satisfying physical dial. But the meaningful design decision was behavioral: it didn't ask you to program a schedule. It watched you for a week and learned your patterns. The human's life, habits, and comfort remained the point; the thermostat served them without demanding you become an HVAC programmer to use it. That is the bicycle — leverage applied to what you were already doing.
Google acquired Nest in 2014 for $3.2 billion. The thermostat became a node in an ambient home intelligence system: a data point integrated into Google's identity and advertising infrastructure, eventually absorbed into Google Home. The pitch shifted to "set it and forget it." But "forget it" is the tell. The goal became to remove you from the loop entirely — stop thinking about your home, stop interacting with it, stop being present in it. The friction being removed was also awareness. The tool stopped amplifying your preferences and started making decisions on your behalf, invisibly, in service of a platform whose actual customers were advertisers. Fadell left Google in 2016.
This is the culture that produced the Crush ad. The team that made it had a mental model where compression = good, efficiency = good, doing more with less = good. The hydraulic press was not violence — it was elegance. They had lost the ability to see what they were destroying, because the things being destroyed — the process of playing piano, of developing your eye with a camera, of writing something difficult and slow — had already stopped mattering to them.

Now we have LLMs, and the confusion has deepened.
The pitch is: "everyone is a creator now." Everyone can generate images. Everyone can write. Everyone can compose music. The technology democratizes creative production. This is not subtext — it is the explicit framing from the people building these systems. Jensen Huang at the 2024 World Government Summit</a>: "It is our job to create computing technology such that nobody has to program. And that the programming language is human. Everybody in the world is now a programmer." Sam Altman has said entire job categories will be "totally, totally gone"</a> as AI agents join the workforce. Dario Amodei has warned that AI could eliminate half of entry-level white-collar roles</a> within five years. The framing is not "here are superpowers for humans." The framing is "here is a replacement for humans, and the efficiency gains justify it."
These are metrics that make sense on a spreadsheet. Efficiency. Headcount reduction. Cost per task automated away. What they don't capture is what humans actually care about: whether the work means something, whether they're growing, whether they made something true and got it into the world. The countercultural tradition that produced the best of early tech cared about those things because it came from people for whom those things mattered personally. The B2B SaaS tradition that replaced it optimizes for the former because that's what closes enterprise deals. This is not malice. It is a profound mismatch between what the tool-builders are measuring and what the people using the tools are actually living.
The consequence of this framing is not just philosophical — it is actively shaping the products. Every AI interface designed under the efficiency logic is answering the same question: what existing task can I make cheaper or faster? The chat box is a support ticket. The AI coding tool is a faster typist. The image generator is a cheaper illustrator. These framings treat AI as a shortcut inside existing workflows, not as a new medium with its own vocabulary and demands. The question Lasseter was asking in 1996 — what new thing can a person do with this that they could not do before? what new medium does this enable? — is not being asked, because it does not close enterprise deals. The result is a genuinely transformative technology being built, sold, and understood primarily as a cost-reduction tool. Which is roughly like Pixar deciding the main value of their renderer was that it made animators faster.
The interface is the most legible symptom of this. The way we interact with AI is through a chat box: text in, text out. The nearest analogy is SMS. This is not an interface metaphor — it is the absence of one. The humanist tradition in computing always cared deeply about interface. Engelbart's 1968 Mother of All Demos</a> was fundamentally about inventing metaphors for thought. The Mac's desktop metaphor was a genuine intellectual achievement: it made the file system legible to non-engineers by grounding it in physical space. HyperCard</a>. VR as Jaron Lanier</a> conceived it — not entertainment but empathy machine, a way to inhabit other perspectives and expand what it means to be a person. These were hard-won insights about how humans think and how technology could meet them where they are. They came from people who read philosophy, who thought about phenomenology and perception, who asked: what is this for, in the deepest sense? The chat interface for AI does not come from that tradition. It comes from: "you know how to text, so text the computer." It is skeuomorphism in the worst sense — dressed in the clothes of text messaging because the people building it never asked whether text messaging was the right metaphor for what this technology actually does.
This is the Syndrome problem. In The Incredibles</a>, the villain's plan is to sell superpowers to everyone — because "when everyone can be super, no one will be." The goal is not to celebrate human capability. The goal is to make human capability irrelevant. The Silicon Valley version: when everyone can generate a painting without learning to paint, the painting is worth nothing, and — more importantly — you have learned nothing. The capacity for judgment, for seeing, for knowing what's good and why, does not develop without practice. Automating out the practice automates out the person.
The process is not a bug. The struggle of learning to draw, to write, to play an instrument — that is not inefficiency waiting to be removed. It is how you become someone with something to say. Philosopher C. Thi Nguyen</a> calls this "striving play</a>" — the idea that we sometimes choose ends specifically because the means are what we actually want. The summit is an excuse to climb. The painting is an excuse to see. Skip the process and you get the output without the person behind it. You get aesthetics without interiority. Gram-worthy, soulless.
Nguyen's work on gamification and value capture</a> is equally relevant here: when you reduce a rich activity to a score or metric, people stop doing the activity and start optimizing the metric. The Instagram camera doesn't just skip the process of learning to see — it installs a new goal (engagement, likes, the gram-worthy image) that actively competes with the old one (making something true). Once the metric is in place, the underlying value gets crowded out.
There is a growing body of research on exactly this — cognitive debt</a>, skill atrophy</a>, the augmentation trap</a> — and the findings are roughly what you'd expect: offload the thinking and the thinking weakens. But the more interesting question is not whether LLMs cause atrophy. It is which skills are being offloaded, and whether those are the ones that mattered.
GUIs made computers accessible to everyone and in doing so made most people unable to use a command line. That is a real loss. It is also, probably, the right tradeoff — most people did not need the command line, and what they gained was worth what they gave up. The question with LLMs is whether the same logic holds. If what gets offloaded is syntax recall, boilerplate, and the mechanical parts of writing — and what remains is design decisions, API and interface choices, abstractions, the judgment calls that actually determine whether something is good — then LLMs could make people better designers in the same way GUIs made computers accessible, while atrophying skills that were always more means than end. You stop thinking about where the semicolons go and start thinking harder about what the system should do and why.
Whether that is actually what happens depends entirely on how you use them. Use them as a crutch and you get the cognitive debt. Use them as a focusing lens — offload the stuff that doesn't require your judgment so your judgment can go where it matters — and you might end up somewhere genuinely interesting. The tool isn't the problem. The orientation toward the tool is.
Agentic AI interfaces push this further in an interesting direction. Complex one-off infrastructure tasks — spinning up a multi-node training cluster, configuring a distributed system, wiring together a pipeline that crosses four different services — used to require either deep specialist knowledge or a specialist to hire. The task was tractable only if you already knew the terrain. Agentic tools make the navigational complexity manageable for someone who knows what they want but not every step required to get there. The human judgment that matters — what am I building, what scale do I need, what tradeoffs am I making — stays with the human. The part that was always just terrain navigation gets handled. This is squarely in the GUI tradition: lower the floor, preserve the decisions that require a person.
The tools Jobs, Lasseter, and Letteri built held to one principle: raise the ceiling on what a human could express while keeping the human as the one doing the expressing. The floor was never technique. It was intent — something to say.
The current generation of AI tools is pitched differently. They are not "here is a more powerful brush." They are "here, let the machine make the creative decisions." The iPhone camera that automatically adjusts your composition, boosts the colors, removes the blemishes — it produces something that looks gram-worthy while systematically removing every decision that would require you to develop taste. Does this save money? Are you more efficient? Does it matter, as long as the output looks good?
Lasseter's framing from 1996 is still the right one. The question is not whether the technology is cheaper or faster. The question is what kind of medium it is, and what it demands of the person using it. Pixar's expensive pencils still required you to be an animator. They raised the ceiling on what an animator could do, but the floor was still: you have to be an animator. The AI camera does not require you to learn to see.
The distinction matters even within AI tools themselves. Gaussian Splats</a> — a new medium for capturing and rendering reality as navigable 3D scenes — use machine learning at their core. The reconstruction is trained. But the human creative experience is not removed because there is "AI" in it. The artist still decides what to capture, how to frame it, what to do with it afterward: relight it, add depth of field, composite 3D objects into it, bend the geometry. When Corridor Crew's Wren used a Gaussian Splat to capture Inspiration Point</a> — a mountain landmark that burned in the LA wildfires — the AI did the reconstruction. The human decided it was worth preserving. That impulse, and everything that flows from it, is irreducibly human. The tool served it. As Wren puts it: "I'm a visual effects artist and my job is to bend reality." The AI is infrastructure. The bending is still his.
Vibe coding</a> — directing an AI to write and iterate on code through natural language — is getting the same dismissal every new medium gets: not real programming, a shortcut that bypasses the work. But the argument applies the wrong floor. The floor of traditional programming was syntax, library APIs, debugging mechanics — terrain navigation. Vibe coding removes that floor the same way GUIs removed the command line. What it does not remove is the judgment that actually makes software good: what are you building and why, what constitutes a correct solution, where are the edge cases that matter, what does acceptable performance look like, when is the AI confidently wrong. These are not syntax problems. They are what separates engineers who understand systems from engineers who can write code. The medium is new. The demands are not gone — they are exposed, because the mechanical layer is no longer there to hide behind. A programmer who cannot articulate what "correct" means, who cannot recognize a plausible-looking solution that fails on the case that matters, who has no taste for what a well-designed system feels like — that programmer is worse off with vibe coding, not better. The one who can do all of that has a new and more powerful pencil.
Critics of AI are mostly reacting against the efficiency discourse — and they are right to. When the loudest voices in tech are promising to eliminate jobs and automate away expertise, the fear is earned. But the critique goes wrong in two ways. The first: it attacks the technology for what the efficiency culture has decided to do with it. AI-as-replacement-engine is a product choice, not a property of the technology — dismissing AI because of how SV pitches it is like dismissing CG animation because Hollywood used it to cut headcount. The second: the argument that AI-generated work is inherently inauthentic — that using AI is cheating, that the human must suffer through the process for the output to count — confuses the tool for the artist. Both errors mistake the medium for the business model of the people currently exploiting it.
Hip-hop</a> built its entire sonic vocabulary on sampling</a> — lifting pieces of existing recordings and recombining them into something new using drum machines</a> and samplers</a>. It was called theft, literally: the copyright lawsuits that followed Grand Upright v. Warner</a> and Campbell v. Acuff-Rose</a> reshaped intellectual property law because the industry could not accept that recombining existing recordings was a creative act. It was. DJ Kool Herc</a> isolating the break in a funk record to loop it indefinitely — using two turntables as an instrument — was not stealing. It was inventing a new medium with two pieces of consumer electronics and a good ear.
The demoscene</a> — programmers and artists making real-time audiovisual art within extreme hardware constraints on early PCs and home computers — was not considered "real" art by the mainstream. It was kids messing around with computers. But the demoscene produced a genuine aesthetic tradition, a competitive community of practice, and a generation of people who understood computation as a creative medium in a way that pure engineers never did. Chiptune</a> artists making music from the sound chips of Game Boys and Commodore 64s were not making real music. Vaporwave</a> — built almost entirely from samples, pitch-shifted and time-stretched, assembled in DAWs by anonymous internet users — was not real music. Flash animation</a> on early internet was not real animation. Autotune</a>, introduced as an imperceptible pitch-correction tool, became an expressive instrument in its own right: T-Pain, Bon Iver, Kanye each made it do things its inventor never imagined, and those are real songs. Every one of these was dismissed as cheating, as not serious, as a shortcut that bypassed the real work. Every one of them produced genuine art made by humans with something to say. The argument "this is cheating" or "this is not real" has been applied to every new computing and electronic tool in the history of making things. It has been wrong every time for the same reason: it mistakes the process for the point, the medium for the message, the tool for the artist.
Gaussian Splats use machine learning. A GarageBand track built loop by loop without touching an instrument is still a song if someone had something to say in making it. Photography was not painting and the critics who said so were wrong. The question is not whether AI was involved. It is whether a human was present as an agent with something to express, making decisions that mattered. That can be true with AI. It can also be absent without it. The hydraulic press that crushed the grand piano contained no AI at all.
Both sides of this argument forget the same thing: culture is always mediated by technology. There has never been a golden age of unmediated human creativity — no pure state of artistic expression that preceded tools. Marshall McLuhan's</a> insight was that the medium is the message</a>: every technology doesn't just transmit expression, it reshapes what can be expressed and thought at all. Writing didn't just record speech — it changed how humans reasoned. The printing press didn't just copy manuscripts — it restructured knowledge and power. The internet didn't just transmit information — it reorganized attention, memory, and identity. DJ Kool Herc's two turntables were not a neutral conduit for pre-existing music; they were a new instrument that produced a new culture. The tools are never neutral. They are never outside the culture. They are part of how the culture thinks.
This means the question is never technology vs. pure human expression. It is always: which technology, designed with what values, serving whose vision? The pro-efficiency builders have answered that question — efficiency, automation, headcount reduction — and called it inevitability. The anti-AI critics have refused to engage with it, by pretending the question doesn't arise if you just reject the tool. But rejecting the tool is not preserving the culture. The culture was always already being shaped by tools. The only real choice is whether you shape the tools back.
The question worth asking of each new tool is still Lasseter's: is this a new expensive pencil in the hands of an artist, or is this the hydraulic press?
There are still companies building cameras that answer this question the right way. Fujifilm</a> is the obvious example. The X-Pro3</a> has a hidden LCD — it flips inward, invisible by default, so the natural state of the camera is: no screen. You shoot. You don't chimp. You commit to the frame. This is a design opinion so aggressive that reviewers complained about it. Fujifilm shipped it anyway. The GFX 100RF</a> goes further: 102 megapixels of medium format sensor in a rangefinder body with a single fixed lens. No zoom. No interchangeable glass. There's a dedicated toggle that steps through a small set of crop-based focal lengths — discrete, deliberate choices, not a continuous zoom you drift through. And then there are the film simulations</a> — Velvia, Classic Chrome, Acros, Eterna — color science decisions you make before you shoot, the way you used to choose which roll of film to load. Not "capture everything flat and decide in post." Not "let the AI pick a look." You choose, now, before you press the shutter. The camera is opinionated and it wants you to be opinionated too.
This is the exact opposite of the direction Sony, Apple, Google, and Samsung are all moving. Their cameras maximize optionality: shoot RAW, bracket everything, let computational stacking</a> extend the dynamic range, run the subject through a neural network, decide the look later. The implicit philosophy is that creative decisions are a form of risk to be deferred. Fujifilm's implicit philosophy is that creative decisions are the whole point, and deferring them is just procrastination. One approach treats the human as the liability. The other treats the human as the tool's reason for existing.

The early internet humanists — Barlow</a>, Brand</a>, Lanier</a> — were utopians but they were also critics. They held the technology accountable to a standard: does this make people more free? More expressive? More truthful to themselves? Does it expand the range of what a human can be?
That critical tradition is what Silicon Valley abandoned. Not because the people there are bad, but because the culture stopped being accountable to it. The question "is this good for human flourishing?" became "does this have product-market fit?" Technology was supposed to be in service of the human process — the messy, slow, necessary work of people making things and becoming, through that making, more themselves. Now the human process is the inefficiency. The friction. The part being optimized away.
The Crush ad is the monument. The bicycle-of-the-mind company made an ad where the hydraulic press is the hero and the grand piano is the problem being solved.
When nobody in the room said "wait" — that is when you know the process has stopped mattering.

Jujutsu is the GOAT but I have no idea how to teach people about it

Unknown — Fri, 10 Apr 2026 00:00:00 +0000

Oh look another nerd deciding to waste more internet bandwidth on all the wonderful virtues of Jujutsu VCS</a>.
I'm not the first and I won't be the last. Here's a sampling of the discourse:

Steve Klabnik's Jujutsu Tutorial</a> — probably the most comprehensive community tutorial</li>
Jujutsu for Everyone</a> — structured for people with zero VCS experience, which is very relevant to what I'm thinking about</li>
Jujutsu in Practice</a> — practical patterns for day-to-day use</li>
Switch to Jujutsu Already</a> — a good intro focused on making the mental model click</li>
Tech Notes: The Jujutsu VCS</a> — first-principles introduction</li>
Jujutsu VCS Introduction and Patterns</a> — covers design consistency and practical patterns</li> </ul>
JJ is worth the hype however, it modernizes one of the most critical components of software engineering, bringing it into the 2020s. The developer experience scales naturally across many axes: small project just starting out <-> large project with tons of developers, local only development <-> multiple remotes moving independently, one user using JJ in a Git world <-> everyone being fully JJ pilled. It saves you from yourself. You can be much more brave about complex VCS operations like rebasing, squashing and cherry picking and the intermediate state tracking allows you to undo and redo operations to recover otherwise lost work. Bookmarks and commit ranges I believe are a superior abstraction to branches. My main complaint is conflict resolution is difficult to do by hand but nothing is perfect out of the box.
I think JJ is good enough that I'd love to introduce it to the students I teach. Maybe it might save them from the classic fresh developer issues like forgetting to push after committing or forgetting to stage commits before commiting or forgetting to pull or forgetting to switch branches, not pushing to master etc. etc. Git is great, in my day as an undergrad schools still used SVN, we clammored to use Git to avoid SVN's problems. The issue with Git is to use it right you need to have a strong mental model confidently navigate common operations and constant vigilance is required to make sure the repository doesn't spiral out of hand.
To use Git properly you need to hold this in your head at all times:
Working Directory Staging Area Local Repo Remote Repo (your files on disk) (the index) (.git/objects) (GitHub etc.) │ │ │ │ │──── git add ────────────>│ │ │ │ │──── git commit ──────>│ │ │ │ │──── git push ───────>│ │ │<─── git fetch ───────│ │<─────────────────── git checkout / restore ──────│ │ │<─────────────────────────────── git pull ────────────────────────────── │</code></pre> Four distinct zones, eight commands to move between them, and the mental overhead of always knowing where your changes currently live. Miss a step anywhere — forget to git add</code>, forget to git push</code>, commit to the wrong branch — and you're debugging your VCS instead of writing code. For experienced developers this becomes muscle memory. For students who are simultaneously learning to code, it's a constant source of friction. So that motivates the question: "What would it take to have students skip Git and go straight to JJ?" What JJ Simplifies</h2> The staging area is gone. The working copy is a commit — JJ automatically tracks every change you make as part of an ongoing, amendable commit. This collapses the four-zone model above into two: your working copy and the repo. The common newbie mistake of "I forgot to git add</code>" simply does not exist. jj undo</code> and jj op log</code> mean mistakes are recoverable. This is huge for beginners. In Git, "I accidentally reset my branch" or "I rebased wrong" can mean real data loss unless you know about the reflog. In JJ, the operation log tracks every action and you can undo them linearly. Students can be brave. Revsets are a powerful query language for talking about commits. Instead of memorizing cryptic ref syntax (HEAD~3</code>, origin/main..HEAD</code>), you write readable expressions. This is a nice on-ramp to thinking about commit history as data you can query. jj describe</code> decouples writing your commit message from the act of snapshotting. You can work, then describe what you did. This maps more naturally to how beginners actually work — code first, explain later. What JJ Doesn't Simplify</h2> Because most code forges (GitHub, GitLab, Bitbucket) are Git-first, students still need to understand enough Git to operate in that world. At minimum, a JJ-first curriculum still needs to cover: Concept</th> Why It Can't Be Skipped</th></tr></thead> Commits</td> The fundamental unit — same in both</td></tr> Remotes</td> GitHub is a remote, this doesn't go away</td></tr> fetch</code> / push</code></td> Still how you sync with the forge</td></tr> Bookmarks vs. Branches</td> PRs on GitHub are branch-based; JJ's bookmarks map onto this but the translation isn't obvious and confuses many people new to JJ</td></tr> </tbody></table> The bookmarks-to-branches translation is the hardest part. When a student wants to open a pull request on GitHub, they need to understand that their JJ bookmark becomes a Git branch becomes a PR. That's three layers of abstraction for someone who just wants to submit their homework. Also without the common tug</code> alias, remembering to move your bookmarks and the exact way to do that can be tedious and easy to get incorrect, potentially poluting the upstream repo What a JJ-First Curriculum Might Look Like</h2> Level 0 — Just track changes locally: jj init</code>, jj status</code>, jj describe</code>, jj log</code>. No remotes, no branches, no pushing. Get comfortable with the idea that every save is being tracked and you can always go back. Level 1 — Work with a remote: jj git clone</code>, jj git fetch</code>, jj git push</code>. Introduce the concept of a remote as a mirror. Still no branches. Level 2 — Collaborate: Bookmarks, how they map to Git branches, opening a PR. This is where the Git-forge translation layer gets introduced explicitly — "the rest of the world uses Git, here's how JJ talks to it." Level 3 — Power tools: Revsets, jj rebase</code>, jj split</code>, jj absorb</code>, jj op undo</code>. The stuff that makes JJ genuinely better than Git for anyone doing non-trivial history management. The Jujutsu for Everyone</a> guide is structured similarly and is worth reading if you're thinking about this problem — they're actively building out exactly this kind of zero-prior-experience curriculum. Open Questions</h2> I don't have a clean answer yet. JJ's core model should be simpler than git if you didnt need to think about git and I believe it is more forgiving for new developers. But the forge ecosystem means you cannot fully escape Git concepts. The question is whether you're better off teaching Git as the foundation and JJ as an upgrade, or teaching JJ as the foundation and Git as a compatibility layer you'll sometimes need to think about. My instinct is the latter. The mental model of "your working copy is always a commit, and you can always undo" is a healthier foundation than "here are four zones and eight commands." We Need Societal Scaling Laws Unknown — Sat, 07 Mar 2026 00:00:00 +0000 In AI research, scaling laws are gospel. Put in $X$ more compute, get $Y$ improvement in capability. The Chinchilla paper, the GPT-4 technical report, every major lab's internal planning documents—they all revolve around trying to develop these predictable relationships between resources and outcomes. Scaling laws are what is used to justify billion-dollar investments. They're why datacenters are being built at unprecedented scale. We have scaling laws for the returns on investment in terms of capability yet we do not have similar normative models for how we believe widespread application of these technologies will change society. We are not running instructive small scale experiments on what a society with LLMs deeply woven in will look like. To be clear from the outset: this is not an argument to slow down. It's that capability research has billion-dollar investment guided by predictive curves. Societal preparation has none of that. The argument here is for foresight, not restraint. LLMs at scale could make institutions more contextually sensitive than they have ever been: capable of seeing people as individuals rather than averages, catching bad-faith exploitation that formal rules can never reach, delivering the judgment that scarcity of cognition forced us to compress into crude metrics. Or it could make them more totalizing and less escapable than anything that came before. Perfect enforcement, crystallized bias, Foucault's Panopticon</a> fully realized, autonomy eroded not by malice but by optimization. LLMs could allow you to be seen as an individual. It also could mean you can never not be seen. Both outcomes are technically possible. This is with LLMs as they are now, imperfect inverse mechanical turks</a> masquerading as oracles. Layers of probabilistic modeling stacked on top of each other. Superintelligence is not required for society to change drastically around this technology. This essay is not arguing that we are saved or we are doomed. It's arguing that we are deploying LLMs into institutions without the instruments to know which trajectory we're actually on. Society is Built on Scarcity</h2> Before the industrial revolution, physical labor was the scarce resource that organized everything—where people lived, how families worked, what children did, how authority was justified. The steam engine dissolved that scarcity, and the consequences weren't mainly economic: it forced into existence the modern city, compulsory education, the 8-hour workday, labor law, the welfare state. Not automatically—through generations of conflict and experiment. The disruption wasn't primarily about wages; it was about what kind of life was possible and what society was obligated to protect. LLMs threaten to do the same to cognitive labor. Every institution we have is downstream of the assumption that cognitive work is scarce and therefore has to be rationed. Tax authorities audit a sample of returns because they can't audit all of them. Food safety inspectors sample products. Financial regulators examine a fraction of transactions. Courts process a fraction of disputes. The entire architecture of governance, markets, law, and expertise is built around one constraint: you cannot check everything, so you check enough to maintain trust. LLMs have the potential to eliminate that constraint. The industry's boldest response is Universal Basic Income</a>: a stipend. UBI is a pure economic answer to what is not just an economic problem. It asks "how do people afford things" and ignores every harder question underneath: what do people do? What gives their lives structure? How do communities cohere? These are moral questions, not monetary ones—the same questions the industrial revolution forced into the open over decades of conflict, which we seem determined to defer again. If you can audit every tax return, what does the IRS look like? If cognitive expertise is no longer scarce, what do the institutions built around rationing it look like? Those aren't economic questions. They're questions about what governance is for. More broadly, ordinary life has always depended on the practical limits of what can be known, tracked, or enforced. Society isn't just built around what rules say; it's built around what rules can reach. A family builds a deck without pulling permits because the permit process is expensive and their neighborhood isn't regularly inspected. A landlord rents a basement bedroom without an egress window</a> in a city with a severe housing shortage because inspectors only respond to complaints, and nobody complains because the tenant needs the housing. Someone moves to a new city and quietly leaves a bad chapter behind them, because records didn't follow people the way they do now. A person asks a friend who happens to be a doctor for informal advice they couldn't afford to pay for officially. A small business owner asks a favor from someone they've known for years rather than going through a formal procurement process that would disadvantage them. None of these are heroic. They're just how life works when the cost of full compliance is high and the probability of being checked is low. The same logic applies beyond individual choices. Communities develop informal economies around what official systems can't or won't serve: the neighbor who fixes cars, the informal childcare network, the loans between members of a family that doesn't involve a bank. Privacy itself has historically been less a right than a byproduct of practical obscurity: your medical history, your spending habits, your location throughout the day weren't tracked not because tracking was forbidden but because it was expensive. The gaps in visibility weren't accidental; they were structural, and people built lives inside them. The intuition is that this is all a failure to be corrected. That if we could just enforce everything uniformly, things would be fairer and better. Sometimes that's true: selective enforcement often falls hardest on people with the least power to push back. But the gaps also do work that's hard to see until it's gone. They're how rules that don't quite fit get quietly negotiated. How communities absorb people who can't meet formal requirements but have nowhere else to go. How ordinary life remains livable under systems that were designed for an average case that doesn't describe everyone. LLMs don't just change enforcement; they change the underlying structure of what can be known and tracked. The question isn't only what laws will be applied more uniformly. It's what kind of life is possible when practical obscurity disappears. Discord's 2026 age verification rollout</a> is a mundane but clarifying example: a platform used by hundreds of millions of people decided that to access its full features, users would need to submit to a facial scan or upload a government ID to a third-party vendor. This happened six months after a breach exposed 70,000 users' government IDs and selfies</a> from a previous verification vendor. The logic is not malicious. The platform has genuine obligations around age-gated content. But the infrastructure being built (verified identity required for full platform participation) is the same infrastructure that makes practical obscurity structurally impossible. What LLMs offer looks like comprehensive uniform governance but it's a black box that trades acknowledged incompleteness for hidden inconsistency. Training data biases, RL artifacts, distributional shift: these produce failures that aren't random and visible like under-sampling, but systematic and opaque, baked into weights no one can fully read. You've swapped a system that knew what it was missing for one that doesn't know what it's getting wrong. There is no avoiding the LLM audit when the LLM audit costs a few hundred dollars of compute. There is a subtler change here: a move from retrospective to live accountability. Every major institution of accountability we have built is fundamentally backward-looking. Courts reconstruct what happened. Regulators investigate past conduct. Auditors review historical records. Trials are an elaborate technology for producing a credible account of the past. The entire architecture of law assumes that what institutions can do is hold people accountable for what they have done: after the fact, episodically, at the cost of enormous effort. That retrospective character is a feature as much as a limitation: it means people live their lives forward, without continuous institutional observation, and face judgment only when someone decides to look. LLMs at scale changes that architecture. Not to the Minority Report style predicting of future crimes, but to something potentially as pervasive: live observation of the present. When every transaction, communication, and movement is processable in real time, institutions don't have to reconstruct what happened; they can watch it happening. This is the shift from episodic accountability to continuous monitoring. It has versions in both directions. The contextualizing version: harm gets caught as it compounds, not years later after a pattern has solidified beyond remedy. The totalizing version: people no longer have the slack of practical obscurity (the room to fail, recover, and move on that an episodic accountability architecture quietly provides). A juvenile record that a judge might have sealed gets embedded in a risk score. A period of financial difficulty that a loan officer might have contextualized becomes a permanent feature of a profile. The difference between those two versions isn't the technology. It's whether the governance layer is designed with the retrospective virtues in mind: that some forgetting is a feature, not a bug. These aren't questions about who gets paid. They're questions about what institutions are for once the scarcity they were built to manage no longer exists. Jeremy Rifkin anticipated part of this in The Zero Marginal Cost Society</a> (2014), arguing that near-zero marginal cost production would erode capitalism and give rise to a collaborative commons. His focus was economic: markets, ownership, profit. The institutional argument is deeper: it's not just that capitalism struggles when things become free, it's that governance itself was designed for a world where you couldn't check everything. James C. Scott's Seeing Like a State</a> (1998) documents this exhaustively: states make society "legible" through simplification (standardized names, censuses, uniform measurement) because "no administrative system is capable of representing any existing social community except through a heroic and greatly schematized process of abstraction and simplification." Hayek made the point in The Use of Knowledge in Society</a> (1945): knowledge is irreducibly dispersed, and no central authority can ever aggregate enough of it to fully govern. Decentralized, spot-check institutions aren't a design failure; they're a rational response to the impossibility of complete information. C. Thi Nguyen's The Score</a> (2025) identifies the tension with decontextualization via quantification. Numbers travel, institutions are built around stripped metrics of society because this is the best we could do to run society in a uniform ("just") way. A credit score can be processed by a thousand different loan officers in a thousand different cities; a nuanced assessment of someone's full financial situation or repayment habits cannot. Metrics strip context so that judgment can scale; however, Nguyen documents what is left behind when this happens—all the nuance dropped, the consequences of centralizing standardized metrics in your life. The technology to change this now exists. Society necessarily changes in a world where the marginal cost of analysis approaches zero. Yet we are operating as if 20th-century institutions smoothly adopt 21st-century capability. "Scalable contextual judgment" is a capability, not a value, and capabilities go in any direction. Replace the credit score with an AI that actually understands someone's financial situation: that could mean fairer lending, or it could mean lenders now have perfect information about every part of your life and no way to improve your credit score. The same dissolution of cognitive scarcity that makes individual judgment richer could make institutional reach total. Which one we build is not a technical question. It's a governance one. Data As Law</h2> In 1999, Lawrence Lessig argued in Code and Other Laws of Cyberspace</a> that behavior online is regulated by four forces: law, norms, markets, and architecture. His warning was that code—the architecture of cyberspace—was becoming the most powerful of the four, and that unlike law, code has no appeals process. It just executes. Law is fuzzy by design. It has context, interpretation, precedent, exceptions. A judge can decide that the letter of a statute doesn't apply to an unusual case. A jury can acquit on conscience. These aren't bugs—they're features, the accumulated wisdom that rigid rules applied without judgment produce injustice. Fuzziness is how law accommodates the infinite complexity of human situations. Code is absolute. An if-statement doesn't care about context. A smart contract executes whether or not execution is fair. Bitcoin doesn't make exceptions. This is precisely what cypherpunks</a> found appealing: rules that couldn't be bent by the powerful, enforced by math rather than men. Code as a replacement for trust in institutions</a>. The ideological throughline from Bitcoin to AI alignment is not accidental. Many of the same people, or at least the same type of people—rationalists</a>, effective altruists</a>, believers in formal systems over human judgment—migrated from crypto to AI safety carrying the same core intuition: that you can encode ethics into a system, that values can be specified precisely enough to be executed reliably. The dream is a Platonic one: a reasoning agent that receives principles and derives correct behavior from them the way a philosopher derives conclusions from premises. Write the right constitution, and the model applies it. The world's best virtue ethicist. Anthropic's Constitutional AI</a> is the most legible attempt at this. They literally wrote a constitution for Claude, a list of principles drawn from documents like the UN Declaration of Human Rights, and trained the model to critique and revise its own outputs against those principles. The name is deliberate: here are the values, encoded in text, now reason from them. The problem is the model isn't doing what the framing implies. A constitution binds a reasoning agent that interprets and applies its principles. What Constitutional AI actually produced is a statistical model fine-tuned to generate outputs consistent with how constitutionally-flavored reasoning appears in text. Those are different things. The model doesn't derive behavior from the constitution the way a judge derives rulings from precedent. It produces outputs that pattern-match to what applying-this-constitution looked like in training data. In distribution, that can look indistinguishable from principled reasoning. Out of distribution, at genuine edge cases, novel cultural contexts, situations the rater pool never encountered, there is no logical guarantee. This is what "prompt injection" is. Its an input that forces the model into a regime where the statistically consitent response violates the governance layer laied on top. The constitution didn't bind the model. It shaped the weights. That gap is where the failure modes live. The Three Laws of Robotics</a> are the most famous fictional attempt at the same program, and the entire corpus of robot stories is a catalog of their failure modes. Not because the laws are badly written, but because the fuzziness they tried to eliminate keeps reasserting itself: every story finds a situation the laws didn't anticipate. Asimov demonstrates that you cannot specify human values precisely enough to execute them reliably, that a reasoning agent genuinely applying rigid principles will eventually encounter a case where the principles conflict or don't reach. LLMs aren't true reasoning agents encountering edge cases in the laws. They do not build conceptual abstractions and manipulate them according to rules in the same way humans might. They're statistical models producing outputs that looked like reasoning in training, which is a subtler and harder-to-diagnose failure mode. The public debate about AI is structured around a question that turns out not to matter: is this thing actually reasoning, or just predicting tokens? The popular conception—the one animating both techno-utopian and extinction-risk discourse—is of a mechanistic human: an agent with goals, values, something like intent. LLMs are not that. But the societal consequences don't hinge on whether it is or not. A statistical parrot deployed at institutional scale, trained on whoever's data, shaped by whoever's rater pool, still makes decisions that govern people's lives. This points to something Lessig's framework didn't anticipate: in a world of LLM-informed governance, data is law. The training corpus is the actual constitution. Whatever was overrepresented in the pretraining data, whatever the rater preferred during finetuning, whatever got filtered in or out—those are the binding documents. They were never written down, have no preamble, nobody voted on them, and you cannot look them up. Constitutional AI wrote a visible constitution on top of a data constitution that already existed and was already shaping every output. The written one is the legible governance layer. The real one is hundreds of billions of tokens of human text, with all its biases and distributional skews baked into weights no interpretability technique can fully read. Data-as-law has different properties from both of Lessig's categories, with distinct failure modes. Code is deterministic and auditable: you can read the contract, find the bug. Law is fuzzy and has appeals: the written text can be challenged, the edge case can go to court. Data-as-law is statistical and opaque: the outputs appear contextual, but the context-sensitivity isn't deliberate like a judge's, it's distributional, a reflection of what the training data happened to contain. The biases aren't in a rule you can find and argue against. They're in the shape of the distribution, invisible until they produce an outcome someone bothered to measure. The approach for encoding ethics varies across labs; the shape is always the same: someone decides what the values are, encodes them through whatever mechanism they've chosen, and deploys the result without the public deliberation or democratic mandate that would be required of any analogous human institution. This is their best attempt at governing AI's societal trajectory, and it operates entirely from the model out, not from society in. It does not ask whether LLMs are pushing institutions toward the contextualizing attractor or the totalizing one. It asks only whether the model behaves. Those are not the same question. And when LLMs with the capability to apply contextual judgment at institutional scale get deployed, the question of whose context it's applying doesn't get answered by writing a better constitution. It gets answered by whoever controlled the training pipeline. The capability to scale judgment is value-neutral. What gets scaled is the data. The Unintentional Regulator</h2> The tech industry operates in a perpetual race. Capture the market before someone else does. Ship the feature before it's commoditized. Train the model before your competitor. Move fast and break things—the motto that defined an era and never really went away, they just have a different slogan</a> now. This isn't a moral failing of individuals; it's game theory. If you don't capture the value, someone else will. The most revealing case is Anthropic. They are, by their own account</a>, the lab most convinced that they might be building one of the most dangerous technologies in human history. They built an entire Responsible Scaling Policy</a> around the premise of not deploying models unless adequate safeguards exist. And then, under competitive pressure, they dropped the flagship pledge</a> that was supposedly the whole point of the company. They operate in a Hegelian</a> sense: the technology is inevitable, history has already decided, so the only meaningful choice is whether the people who take the risks seriously get there first. Existential concern about AI is now an argument for building faster, not slower. Ironically, despite tens of thousands of words in think pieces on the implications of AI and entire research fields devoted to alignment and safety, the most effective governor on AI development turned out to be TSMC's N3 process yield rates</a>. Not a law. Not a treaty. Not a democratically mandated pause. A semiconductor fabrication bottleneck and a lack of cheap electricity. NVIDIA's Blackwell architecture shipped roughly 1.5 to 2 million units in 2025</a> not because anyone deliberated about whether society was ready, but because of the limitations of lithography throughput, DDR5 yields at Micron, how many generators you can buy. The most consequential "AI governance" decision of 2026 was made in a fab in Hsinchu and city council meetings about substation lead times. Physical reality is doing what policy couldn't. That bottleneck is being engineered away on both sides of the geopolitical divide as aggressively as possible. The export controls that weaponize this bottleneck in order to slow China down are demonstrably not working</a>: DeepSeek built frontier-competitive models on restricted chips by programming around their bandwidth limitations at a lower level than CUDA</a>; the controls didn't slow them down, they forced an efficiency breakthrough. Huawei is planning to double Ascend AI chip output in 2026</a>. When those constraints loosen, we'll discover that we never actually built a governance system. We just got lucky that the supply chain was the bottleneck first. When compute costs drop by a factor of ten, and despite the end of Dennard scaling</a>, they likely will, what required a hyperscaler becomes feasible for a startup, then a hobbyist. Crucially, supply chain physics don't resolve the tension; they only control the speed at which we approach it. Whether LLMs in institutions converge on the contextualizing attractor or the totalizing one is not a question wafer yields can answer. The Laziness of Extinction Discourse</h2> The community that should be asking 'which future are we building?' is asking a different question entirely. The popular public discussions about AI safety began with a focus on extinction risk: will superintelligent AI decide to eliminate humanity? Will we lose control of systems more capable than ourselves? The focus on extinction is a failure mode disguised as rigor. It has the aesthetic of serious thinking (philosophical depth, civilizational stakes) while actually functioning as an escape hatch from the harder, messier, more tractable questions about the society we're building right now. Extinction is the one scenario where you don't have to do the institutional work, because if it happens there are no institutions left to fix. It's the most intellectually convenient possible framing. Extinction is binary. We survive or we don't. It lets you skip the infinite gradations between "everything is fine" and "everyone is dead": where the actual future will lie. A world where AI works but democracy doesn't isn't an extinction scenario. Neither is a world of abundance and spiritual emptiness, where we solved AGI but not meaning. Neither is a world where the people building these systems made choices about whose values to encode without any democratic mandate, and we only noticed after the fact. These aren't edge cases. They're the likeliest futures. And extinction discourse has nothing useful to say about any of them. There's also a practical problem: it's been a decade of serious public investment in x-risk as a framing, and the main thing it has produced is a community with a strong aesthetic identity and a negligible effect on actual deployment decisions. The labs that take existential risk most seriously, Anthropic, have sped up not slowed down. The framing has not generated the institutional responses or the governance infrastructure that would constitute taking it seriously. It has generated a lot of essays, a lot of funding for capability research disguised as safety research, and a career path for people who want to think about AI without thinking about any specific deployment or variant of "AI". The deep questions about an AI-native society go unasked because they're hard and ultimately human-centered, not technological. Consider: the personal computer has existed for roughly 45 years, the internet has been mainstream for 30, and we're still working out their second and third-order effects: cybersecurity, mass data collection, algorithmically mediated media. The speculation was extensive at the time about what the cyber-future will hold and how we should manage cyberspace: Alvin Toffler's The Third Wave</a> (1980) anticipated the information society before the PC was widespread; Nicholas Negroponte's Being Digital</a> (1995) predicted digital convergence with remarkable accuracy; Howard Rheingold's The Virtual Community</a> (1993) mapped online social life before most people had experienced it; John Perry Barlow's "A Declaration of the Independence of Cyberspace"</a> (1996) staked out the libertarian governance vision that still shapes platform policy today. We did not lack for vision. Yet there were still deeply disturbing unforeseen outcomes. And we are even blinder now in the era of LLMs. LLMs at institutional scale could move society toward institutions that are finally able to hold contextual complexity, or toward institutions that are more totalizing and less escapable than anything we have built before. Extinction discourse has nothing useful to say about which of those we're headed toward, because both of them involve humans surviving. The Moral Machine 1</a></h2> ^1The term borrows from MIT's Moral Machine</a> experiment (Awad et al., Nature, 2018</a>), which crowdsourced human moral judgments about autonomous vehicle decisions across millions of participants in 233 countries. The experiment revealed substantial cross-cultural variation in moral intuitions (who to spare in a trolley-problem-style crash) and is a systematic attempt to empirically map the terrain of human moral judgment at scale. Its lesson was not that moral consensus exists and can be extracted; it was that moral intuitions are culturally contingent, contested, and resistant to simple aggregation. Any "moral machine" faces that problem first. </div> Philip K. Dick's The Minority Report</a> is an illustration of what algorithmic governance looks like at institutional scale: a pre-crime system that arrests people for murders they haven't committed yet, based on probabilistic prediction. The horror isn't that it's wrong; the predictions are largely accurate. The horror is what it means to live in a society organized around algorithmic certainty rather than demonstrated action. Guilt becomes statistical. Justice becomes actuarial. The system is more accurate than human judgment and also more inhuman. Take a real judge. Today, judicial discretion is a feature, not a bug. Sentencing guidelines exist, but judges can depart from them. A first-time offender with extenuating circumstances gets treated differently than a repeat one. A prosecutor can decline to pursue a case they consider unjust. The system is leaky by design, because the alternative (rigid rule application without context) produces outcomes so obviously wrong that every legal tradition across history has built in escape valves. The same tension applies when LLMs allocate jobs, admit students, set insurance rates, and decide parole, it could eliminate the nepotism and bias that currently shape these decisions. It could also calcify whatever assumptions were baked into training data, producing a more rigorous version of the same discrimination with less recourse. When a human rejects you, you can argue, appeal, find another human. When a system does, the decision feels categorical, produced by something that doesn't negotiate. Less discriminatory hiring, more consistent sentencing: these could all be genuine improvements. But we would be arriving at them without the governance infrastructure to make them legitimate. The problem Lessig identified used to cut both ways. Yes, encoding ethics into hard rules strips out the fuzziness that makes law humane. But fuzziness also has a cost: it was expensive to apply. Judgment takes time and expertise. You can't hire enough judges, regulators, or compliance officers to apply contextual reasoning at the scale that modern systems operate. So we defaulted to rules. Not because rules are better, but because rules are cheap. That tradeoff is now shifting. We've had mechanisms for fuzzy judgment before. The jury is one. A group of peers, drawn from the community, asked not to apply a rule but to reach a verdict: to decide what a reasonable person would find. Lessig also points to deliberative polls</a>: randomly sampled citizens given balanced information and time to discuss, whose considered opinions turn out to look quite different from snap poll responses. Both are attempts to extract something like collective moral judgment without reducing it to a rule. Both are expensive, slow, and impossible to scale. A jury deliberates for days over a single case. A deliberative poll costs millions and takes months. They work, in their domain. But you can't run a jury on every financial transaction or a deliberative poll on every norm violation. However, Nguyen's diagnosis points directly at what's new here. The gap Lessig identified (between what law says and what norms expect) exists precisely because enforcing norms requires context, and context doesn't travel. The moment you formalize "exploiting the spirit of the rule," clever actors find a new way to comply with the letter of your formalization while violating its spirit. Every attempt to encode a norm into a rule just moves the gap. The underlying problem is that norms are about the whole situation (intent, pattern, effect, social meaning) and rules can only address specified features of situations. What LLMs offer is a system that might hold context without collapsing it into a score. Not a metric, but something closer to the judgment that generates metrics: pattern recognition across entire situations, including the parts that didn't fit neatly into the rule. Norms are implicit, contextual, and hard to articulate, but not to an LLM trained on billions of examples of human communication about what's fair and what isn't. How do you write a regulation that catches someone acting in bad faith? You might not need to write it. You might be able to describe the situation and ask. It's also worth being clear that the system described in the rest of this section (a moral machine capable of reliable contextual norm enforcement) does not currently exist but is easy to imagine from current techniques and in no way requires general superintelligence to be convincing enough to deploy at scale. </blockquote> Consider what this looks like in practice. High-frequency trading firms spend enormous resources finding strategies that are technically legal but structurally extractive; they don't buy and sell based on economic fundamentals, they arbitrage market microstructure in ways that impose costs on other participants without creating value. No specific rule is broken. Every individual transaction is legal. But the aggregate behavior is a kind of predation that most market participants would recognize as wrong if they could see it clearly. Rules-based regulation can't catch it because catching it requires reasoning about intent and effect across a pattern of behavior, not just checking whether individual transactions conform to specified constraints. The SEC issues guidance, adds new rules, watches the strategies mutate. It's an arms race that the regulators are structurally losing. An LLM-based system asked to evaluate whether a trading strategy is fair (not whether it's legal) can reason about the question the way a thoughtful senior regulator would. Is this adding liquidity or extracting it? Is this participant providing a service to the market or imposing costs on it? Does the pattern, taken as a whole, serve or undermine the purpose markets are supposed to serve? These aren't algorithmic questions. They require the kind of contextual reasoning that formal systems have never been able to automate. Until now. This opens something genuinely new: the possibility of identifying violations of norms rather than just laws. A "moral machine" that doesn't ask "did this actor violate rule 47(b)(2)?" but "did this actor behave in a way the community would recognize as wrong?" The difference is enormous. You could catch the tax lawyer who finds every loophole without breaking any rule. The company that technically complies with environmental regulations while deliberately undermining their intent. The landlord who never explicitly discriminates but systematically makes certain applicants' experience unpleasant enough to withdraw. These are norm violations that current law cannot reach: not because no one has tried to write the rules, but because the behavior is defined by context and intent that formal specification cannot capture. This is not a simple good. Enforcing norms at scale means someone decides whose norms. The informal non-enforcement that allows communities to signal that a law is outdated, that makes space for civil disobedience, that permits the kind of friction where moral progress actually happens: that gets foreclosed too. A moral machine powerful enough to catch bad-faith exploitation is powerful enough to enforce consensus morality uniformly, without appeal, without exception. The same capacity that could fix high-frequency trading abuse could enforce social conformity. Foucault's Panopticon</a> again, but now it's watching for spirit-of-the-rule violations, not just rule violations. China's social credit system is the preview everyone points to. But what makes it troubling isn't really the LLMs; it's the values encoded in the system and the absence of any check on those values. An AI-mediated society with strong civil liberties, democratic oversight, and genuine recourse mechanisms could look different. The problem isn't LLMs in institutions. The problem is arriving at AI in institutions without considering the oversight layer that makes it legitimate. What the oversight layer would actually look like is worth speculating about concretely, because the abstract version ("democratic oversight," "civil liberties") doesn't do the work. Consider a different model: a standing deliberative body, convened not to pass a law but to build a model. Citizens, drawn like jurors from the community that will live under its decisions, spend weeks deliberating over the values they want encoded in the AI systems that govern them. What counts as fair hiring in this jurisdiction? What level of past conduct should stop counting against someone? When does pattern-of-behavior monitoring become surveillance? The outputs aren't statutes. They're preferences: training data, principles expressed in the form that AI systems can actually consume. Deliberative polls have extracted considered judgments on contested issues across dozens of countries. The missing piece, if AI is going to be deployed broadly through society, isn't any single technology or institution; it is a process with democratic legitimacy, subject to ongoing audit and revision by the community that created them. None of that is technically impossible. What it requires is deciding that the legitimacy problem is real: that the question "whose values are encoded?" deserves a democratic answer rather than being settled by whichever research team's cultural assumptions happened to shape the reward model. Meanwhile, the panopticon isn't a hypothetical—it's being assembled now, not through any deliberate plan but through a thousand independent procurement decisions nobody is watching. Automated systems determine benefits eligibility, flag suspected fraud, set insurance rates. Courts use risk assessment tools in bail hearings and sentencing. Facial recognition runs in transit systems and public spaces. Palantir's Gotham platform</a>, deployed across hundreds of law enforcement agencies, lets an officer start from a single name or license plate and retrieve email addresses, phone numbers, bank accounts, Social Security numbers, and family relationships, then auto-track every person in the resulting network. In 2025, ICE awarded Palantir a $30 million contract to build ImmigrationOS</a>, integrating travel histories, biometrics, social media, Medicaid records, IRS data, and license-plate readers into unified AI-driven profiles on individuals, drawing on data from agencies with no legal mandate to share it for immigration enforcement. Flock Safety</a>, now deployed across more than 5,000 communities, operates a national network of license-plate readers that passively logs every vehicle's movements—data pooled across jurisdictions and queryable by any participating law enforcement agency with no warrant required. Real-time crime centers</a>, now operational in dozens of major cities, aggregate these feeds alongside gunshot-detection sensors, surveillance camera networks, and social media monitoring into unified analyst dashboards, converting what were once separate procurement decisions into something approaching continuous observation of public space. Each piece was someone solving their own problem: the agency wanted better tools, the vendor had a product, the contract got signed. Most people living under it have no idea it's there. The totalizing attractor doesn't need a master plan. It just needs everyone to keep optimizing locally while no one asks what they're building together. There is a version of this that resolves toward the contextualizing attractor, not the totalizing one. The failure mode of metric-based institutions is that they treat people from different contexts as if context didn't exist: the same credit score formula applied everywhere, the same sentencing guideline regardless of circumstance, the same test score as the measure of a student. This produces a particular kind of injustice: technically consistent, contextually blind. The promise of AI-native institutions, properly governed, is something different: systems that can see context and still aspire to consistency. A sentencing model that can hold the full circumstances of a case and still be audited for disparate outcomes</a> across race or class (the kind of structured algorithmic audit that Sandvig, Hamilton, Karahalios, and Langbort developed as a research methodology precisely for detecting discrimination in opaque systems). An admissions system that can evaluate a student's actual trajectory rather than their GPA, without the nepotism that currently fills the gap when human "holistic review" becomes cover for preference. These aren't guaranteed improvements. But they describe a real possibility that metric-based systems, by design, can never achieve: judgment that travels with its context rather than by stripping it away. Conclusion</h2> The accidental regulator (TSMC's yield rates, grid interconnection queues, the fact that 3nm lithography is hard) bought us time. We didn't earn it. Every efficiency breakthrough DeepSeek finds, every fab TSMC opens, every GPU off the production line is time running out on a clock we never started. The public discourse about what to do with that time has been captured by the AGI question: will it be conscious? Will it take over? Will it kill us? These are the wrong questions. Every institution that deploys an AI-based system is already operating under data-as-law, whether or not anyone named it that. The training corpus is already the constitution. The rater pool already encoded preferences. This is the thing the extinction discourse spent a decade not asking. It isn't about superintelligence. It doesn't require AGI. It's happening with the systems that exist right now, at the scale they're deployed right now, in the institutions that are quietly replacing spot-checks with models nobody voted to build. The facade of the AGI debate makes it easy to defer: we'll govern this once it gets serious. It's already serious. The governance gap isn't ahead of us. It opened the moment the first procurement decision was made. The new rules aren't written down anywhere. That's the point. Data is law, and unlike every previous form of law, you cannot read it, cannot cite it, cannot challenge it in court. It has no preamble stating its purpose. It has no amendment process. The US military used Claude to select over 1,000 targets in the first 24 hours of strikes on Iran</a>—all run through weights shaped by a rater pool nobody voted to convene, applying values nobody publicly deliberated, with no written record of what was decided or why. It does not know what it got wrong. The cognitive scarcity that forced institutions to strip context out of judgment is dissolving, and the thing replacing it could finally restore that context or it could be the most complete instrument of control ever assembled, enforcing not just rules but norms, not just laws but the full shape of whoever's training data happened to dominate. Scaling laws for capabilities exist because someone decided to run the experiments: vary the compute, measure the loss, find the curve. We don't have societal scaling laws because we haven't run the equivalent experiments. Some of them are obvious enough to start. LLMs are not inscrutable technology. Even if we don't know how it works, we know how to make it. We can develop societal practices around it. What happens when RLHF is treated like a vote — with franchise requirements, transparency, and an auditable record of what was decided? What does training data look like when it goes through a deliberative assembly instead of a contractor's annotation queue? What if democratic AI weren't a slogan but a methodology: citizens' assemblies that produce preference specifications, small-scale pilots in low-stakes institutions, iterated and measured? The point isn't that any of these would work. The point is that we don't know, because nobody is trying. The labs run thousands of ablations to understand what changes a model's capabilities. Nobody is running ablations to understand what changes a society's trajectory. That asymmetry isn't inevitable. It's just where we chose to put the resources. Lots of different LLM based tools were used in the writing and research for this essay </blockquote> SWE Automation Is the Killer App Unknown — Sun, 08 Feb 2026 00:00:00 +0000 The UI Moment, Again</h1> In November 2022, ChatGPT's launch felt like a paradigm shift</a>. Suddenly, everyone was talking about AI. The technology press couldn't stop writing about it. Your relatives asked you about it at Thanksgiving. It seemed to appear overnight. But it didn't appear overnight. Large language models had existed for years. GPT-3 launched in 2020. BERT came out in 2018. The transformer architecture that powers all of this dates back to 2017. Researchers had been steadily improving these systems, publishing papers, iterating on architectures, scaling up training runs. What changed in November 2022 wasn't the underlying technology. It was the interface. ChatGPT put a language model behind a chat interface and let anyone use it for free. No API keys, no Python notebooks, no papers to read. Just a text box and a conversation. That interface unlocked something. It made the capability legible to non-researchers. People could feel what the model could do by talking to it. The chat format was familiar—everyone texts, everyone uses messaging apps. Within that familiar frame, the AI's capabilities became visible. It could write, reason, explain, code, analyze. The technology had been there, but the interface made it undeniable. This is how technologies break out of research labs. Not through incremental improvements to benchmarks, but through interfaces that make capabilities viscerally obvious to normal humans. The Industry Is Stumbling Around in the Dark</h2> Since ChatGPT's launch, we've seen an explosion of AI applications. Every software category has been AI-ified: Search: Perplexity, ChatGPT search, Bing Chat</li> Writing assistants: Notion AI, Google Docs AI, Grammarly</li> Image generation: Midjourney, DALL-E, Stable Diffusion</li> Video generation: Sora, Runway, Pika</li> Voice: ElevenLabs, voice cloning, AI podcasts</li> Music: Suno, Udio, AI-generated soundtracks</li> Customer service: AI chatbots on every website</li> Personal assistants: Replika, Character.AI, custom GPTs</li> Education: Khan Academy's Khanmigo, Duolingo Max</li> Design: Figma AI, Canva AI, Adobe Firefly</li> Productivity: Mem, Notion AI, meeting transcription</li> Code: GitHub Copilot, Cursor, Claude Code, Devin</li> </ul> The list goes on. There's an AI tool for everything. Venture funding has flooded into AI startups. Every company is adding "AI-powered" to their feature list. We're in the hype phase. What Sticks?</h2> But hype cycles pass. The question isn't what's hot right now, but what remains when the novelty wears off. What application of LLMs is so fundamentally valuable that it becomes infrastructure? What's the killer app that justifies all this investment and attention? The answer is software engineering automation because it's the one where: The value is measurable</li> The users are willing to pay</li> The technology is good enough</li> The feedback loops are strong enough that the tech doesn't need to be perfect</li> It compounds: better tools make better tools</li> </ul> The Value Is Measurable</h3> Most AI applications exist in fuzzy value territory. Is an AI-generated image "better" than one you'd commission from an artist? Depends on your taste. Does an AI writing assistant make you a better writer? Hard to say, maybe you'd have written something better yourself given time. They maybe faster to make on the surface but they are still distingushable from human images and text enough that you may spend as much time fixing them up as it took to make it from scratch. Software engineering is different. The value is concrete: Did the code work? Yes or no. It either compiles, passes tests, and does what it's supposed to, or it doesn't.</li> How fast was it delivered? You can measure velocity—features shipped per sprint, time from spec to deployment.</li> How many bugs were caught? Fewer production incidents, faster debugging cycles—these are trackable metrics.</li> </ul> There's no subjectivity. If an AI coding assistant lets you ship twice as fast and produce the same results, that's not a matter of taste. It's a measurable business outcome. And the business outcomes are enormous. Software engineering is expensive. Senior engineers at tech companies make $300K–500K+</code> total comp. At scale, even modest productivity gains are worth millions. If an AI tool makes a 100-person engineering team 20% more productive, that's like adding 20 engineers—$6–10M</code>year in value. Companies will pay for that. They already are. Users Who Are Willing to Pay</h3> Consumer AI applications face a harsh reality: users expect AI to be free. In the long term, it will be "free" . Costs for power, maybe some hardware, but you won't subscribe to some service. Fundamentally, there are few moats in AI. The data is largely publicly available (give or take discussions of fair use). The model architectures for LLMs are publicly disclosed. The fundamental gatekeeper is access to compute. Even then, through techniques like model distillation and quantization, the vast majority of capability can be captured and run on very limited hardware. The current barriers for self-hosted consumer AI come down to ease of setup, use, and maintenance (another UI revolution yet to come). But as many who have instituted paywalls (newspapers, apps, etc.) have found, even charging one cent for your service causes a drastic reduction in your userbase. I fully expect that in the long term, consumer AI will be serviced by something akin to a personal AI computer, a device you'd buy from a manufacturer like Apple that gives you a simple interface to a local model that feels no worse than the trillion-parameter Opus-class models running in datacenters. Businesses have a different value calculus and are far less cost-sensitive. Time and human capital are as important as dollars. Being able to move faster with fewer resources is worth the extra monetary cost. SaaS as a business model has demonstrated this. Workday, Justworks, JIRA, Slack, Tableau, all companies that automate common business functions, allowing companies to have less support staff, move faster, and coordinate better. This doesn't mean you don't have HR specialists or project managers or accountants or data analysts, but you certainly don't need as many. For a long time, software engineering was an exception. It was a high-skill job, and for the most part you could never have enough great engineers. But with tools like Claude Code, one senior engineer with clear intention can implement a feature that used to take a month and a few junior implementers. A $20</code>/month AI coding assistant that saves even an hour per week is worth 10x its cost for an engineer making $150K</code>/year. There's also a management aspect: regulating access to codebases and infrastructure, enforcing best practices. Having a company-wide provider of AI services allows some semblance of control and guarantees about how employees conduct their work. The Technology Is Good Enough</h3> Many AI applications are still in the "impressive demo, rough product" phase. AI-generated video is stunning for 10 seconds, then the physics break. AI music sounds plausible until you listen carefully. AI search is great until it confidently hallucinates. Code generation has crossed a threshold. It's not perfect, but it's useful right now. Why is code different? A few reasons: Verification loops: Code either runs or it doesn't. Tests pass or fail. The compiler catches type errors. There's immediate, deterministic feedback that lets the AI iterate toward correctness. This is unlike creative tasks where "correctness" is subjective and subtly encoded into the product. Massive training data: Code is public (GitHub, Stack Overflow), structured, and abundant. LLMs have seen millions of repositories and billions of lines of code. They've learned patterns deeply. Clear intent from context: When writing code, the surrounding context—existing functions, type signatures, comments, variable names—provides strong signal about what should come next. The AI isn't generating from a blank slate. Tolerance for iteration: Developers already iterate. Writing code is revising code. An AI that generates something 80% right that you refine is still a massive win. You don't need perfection, just a good starting point. This combination means code generation is past the toy phase. It's delivering real value in production workflows today. Feedback Loops Provide Leniency to Imperfect Systems</h3> This might be the most important factor. AI coding assistants achieve tasks via feedback. Where there's a strong pass-or-fail signal, with enough iteration an AI agent can solve the problem to some degree. Compare this to other AI applications: AI art: Users either like an image or they don't. Taste is subjective. Hard to use that to improve the model systematically.</li> AI writing: Did this make the writing "better"? Hard to measure. Most users can't articulate why they prefer one version over another.</li> AI search: Did the answer satisfy the user? Maybe they closed the tab because they found what they needed, or maybe because the answer was wrong. Ambiguous signal.</li> </ul> Even when users have preferences, you end up with what we see in consumer-facing chat interfaces: degenerate behavior like sycophancy gets reinforced even when humans know it's suboptimal. People love having their egos stroked, and due to how models trained against human feedback this behavior gets reinforced. Code has ground truth. The compiler and tests are the judge. This lets AI coding tools improve faster than other applications. Additionally, the code generation task aligns with LLM strengths. LLMs are pattern-matching engines trained on vast amounts of text. Code is structured, pattern-rich, and well-represented in training data. It Compounds—Better Tools Make Better Tools</h3> AI coding assistants make themselves better. The teams building Cursor, Claude Code, and GitHub Copilot use their own tools. This use case is being dogfooded more than any other at the companies developing LLMs. As people say in product design, the best products are the ones you make for yourself. This is a compounding loop that doesn't exist for most AI applications. AI-generated art doesn't help you build better art generators—it probably makes them worse. AI writing assistants don't make it easier to train better writing models. But AI code generation directly accelerates AI research and development. This suggests a future where AI-powered software development accelerates—not because models get bigger (though they will), but because the tools for building models get more targeted on this use case, where the feedback signals are most observable. The Staying Power</h2> When the current AI hype cycle cools, what remains? Some consumer AI apps may stick. Chat-mediated research probably survives. AI-generated art may become a standard tool for certain creative workflows, particularly in marketing where art is commodified. Voice AI for transcription and customer service likely becomes commodity infrastructure. But I think the most durable, highest-value application is software engineering automation. This doesn't mean programmers disappear. It means programming changes. The job shifts from writing every line by hand to directing AI systems, reviewing their output, and focusing on architecture and intent. The cognitive load moves up the stack. But unlike other AI applications that might be fads, coding automation has staying power because it's embedded in the critical path of building everything else. Every software company, every tech product, every digital service—they all need code. Making that code faster and cheaper to write is valuable to everyone. The Interface Moment for Coding Agents</h2> Just like ChatGPT made LLMs legible to the general public through a simple chat interface, we're approaching an interface moment for coding agents. Until recently, AI coding tools were mostly autocomplete-plus. Copilot suggests the next line. Cursor helps you edit faster. These are powerful, but they're incremental improvements to existing workflows. The interface moment is here: the abstraction level is shifting. Instead of writing code and having AI assist, you describe intent and AI generates working systems. The unit of work isn't "write this function" but "build this feature" or "refactor this architecture." When this interface matures, when the abstraction is natural and the reliability is high enough that you trust it, that's when coding automation becomes truly sticky. Not just for early adopters and AI enthusiasts, but for every engineer, every team, every company, normal people. Conclusion</h2> ChatGPT's launch wasn't about new technology. It was about making existing technology legible through the right interface. The chat box made LLM capabilities undeniable to millions of people. Coding agents follow the same pattern. The technology isn't new or novel. What's coming is the interface refinement that makes software engineering automation natural and reliable. It will also expose software engineering to people who have no clue how to write a single line of code or what a command line is. It's no longer a novelty or a power-user tool. It will be infrastructure—the default way software gets built. That's the killer app. The one that remains when the hype fades. The one that justifies the investment, the attention, and the transformation. The Definition of Good Software Ergonomics Has Changed Unknown — Thu, 05 Feb 2026 00:00:00 +0000 The Vibe Coding</del> Automated Programming Revolution</h1> Software engineering is fundamentally changing. AI coding agents like Claude Code have put the vision of just telling a computer to do something in natural language and it just working out of the box in sight - the kind of natural language computer interface</a> that Star Trek: The Next Generation and other science fictionpromised decades ago. This approach emphasizes directness and velocity over precision. You describe what you want, the AI generates something close, you iterate until it feels right. However, as we embrace more stochastic, probabilistic code generation, the need for deterministic, pedantic verification systems has become more critical, not less. The definition of good ergonomics in software tools has fundamentally changed. "Annoying and verbose" type systems that once felt overly burdensome are now precisely what makes automated programming viable for production systems. The Old Ergonomics: Flexibility vs. Safety</h2> Python/JS: Maximal Expressiveness</h3> For decades, languages like Python, Ruby, and JavaScript defined "ergonomic" programming. They clearly made design decisions prioritizing: Rapid prototyping: Write code without upfront type declarations or boilerplate</li> Low friction: No compiler to satisfy, just run your code and see what happens</li> Expressiveness: Duck typing lets you write generic code without ceremony</li> Approachability: New developers could be productive quickly</li> </ul> The goal a lot of programmers have is "what is the shortest path to getting something running". And Python and JavaScript are great choices for this because of their flexibility. This made perfect sense when humans were the primary authors. We have the full context of what we just wrote and over time this knowledge grows, so we can make informed decisions about additions or subtractions from the programs. We intuitively understand types from variable names and usage patterns. We catch obvious mistakes as we go. The cognitive overhead of static types felt like friction against our natural workflow. Python became the language of ML precisely because of these properties. When you're iterating on model architectures or experimenting with data transformations, you want to think about the problem, not satisfy a type checker. The Deal We Made with the Devil</h4> But this flexibility came with costs that we grudgingly accepted: Runtime surprises: AttributeError</code>, TypeError</code>, KeyError</code> appearing in production</li> Refactoring anxiety: Changing a function signature requires manually hunting down all call sites</li> Integration fragility: Connecting components means carefully reading documentation and hoping you followed the library and language right</li> Testing burden: You need comprehensive test coverage just to catch new bugs</li> </ul> We built elaborate defensive strategies: extensive unit tests, runtime assertions, careful code reviews, gradual typing systems like TypeScript and mypy. But fundamentally, we relied on human vigilance to catch what the language wouldn't. This was manageable when humans wrote all the code. We could be careful. We understood our codebases. We had context. Rust: Maximal Safety</h3> Consider the common complaints about Rust today. Developers constantly cite "fighting the borrow checker"</a> as a major pain point. Lifetime annotations are confusing. The compiler is pedantic about ownership and mutability in ways that feel unnecessarily restrictive. You write what seems like perfectly reasonable code and the compiler rejects it with cryptic error messages about borrowed values not living long enough. Simple tasks that take five minutes in Python require 30 minutes of appeasing the type system. The learning curve is brutal. All of this is true when a human is writing Rust character by character. The cognitive overhead of tracking ownership, satisfying lifetime requirements, and structuring code to make the borrow checker happy is immense. You're trying to solve a problem while simultaneously managing low-level memory safety invariants. But with AI-assisted development, this dynamic inverts completely. The LLM doesn't experience cognitive overhead from the borrow checker. It will happily try 20 different lifetime annotations until one works (provided youre willing to pay for the tokens). It doesn't get frustrated when the compiler complains about moving a value that's still borrowed. It just generates a new version. The "fighting the borrow checker" experience - which exhausts humans - is exactly what LLMs are built for: rapid iteration against deterministic feedback. // You: "create a user service that fetches users and validates email" // AI generates, borrow checker complains, AI regenerates, repeat 15 times... // You see only the final result: fn get_user(id: UserId) -> Result<User, Error> { // ... implementation } fn validate_email(user: User) -> bool { // ... implementation } fn process_user(id: UserId) -> Result<(), Error> { let user = get_user(id)?; // AI accidentally tries: validate_email(user.email) // COMPILE ERROR: expected User, got String // AI immediately fixes: validate_email(user) // ✓ compiles }</code></pre> The compiler catches that the agent initially mixed up user.email</code> and user</code>. No runtime error in production, no unit test needed for this specific case. The type system caught it mechanically, the AI fixed it automatically, and you never saw the 15 iterations it took to satisfy the borrow checker. The complaints about Rust's difficulty are really complaints about the human experience of satisfying its strict requirements. But those strict requirements are precisely what make it ideal for AI-generated code. The pain points for humans become verification points for AI. Declarative Infrastructure: The Nix Example</h3> The same pattern extends beyond code to systems management. Declarative, reproducible infrastructure tools like Nix represent another case where what seemed like excessive rigor for human operators becomes ideal for AI agents. Traditional imperative systems administration - running sequences of apt install</code>, systemctl enable</code>, editing config files, hoping everything works - is error-prone and fragile. It works when experienced sysadmins carefully maintain mental models of system state and manually verify each step. But it's a nightmare to automate reliably because there's no verification that the system ended up in the desired state. Tools like Ansible improved on raw shell scripts by adding idempotency and a declarative veneer, but they still operate imperatively under the hood - checking current state, computing diffs, applying changes. When an Ansible playbook fails halfway through, you're left with partial state and have to reason about what succeeded and what didn't. Nix flips this model. You declare what you want: Python 3.11, PostgreSQL 15, these exact library versions, with these configuration files, and Nix handles the how. More importantly, Nix provides strong guarantees: builds are reproducible, rollbacks are atomic, different configurations can coexist without conflict. The system either successfully reaches the declared state or fails clearly, with no partial success states. However, many decry Nix's obtuse syntax</a> and steep learning curve. Many developers take one look at Nix and decide apt install</code> is good enough. They want to think imperatively not wrestle with recursive attribute sets and mkDerivation</code> functions. Consider asking an AI to write a bash script that installs dependencies, configures services, and sets up an environment. The AI has to reason about: What packages are already installed? What version? Will this conflict with something else? Did the previous step succeed? Is the service already running? Every system is unique. The AI generates plausible commands that might work, but verification requires actually running them and seeing what breaks. With Nix, the AI writes a declarative configuration. The Nix evaluator immediately catches errors. When you build it, you get exactly what was declared, reproducibly, every time. The AI handles the ceremony of Nix syntax and package resolution while the human specifies intent. The declarative substrate provides verification that what gets built matches what was intended. With AI agents, you can have it both ways. You express your intent imperatively and naturally: "Install PostgreSQL 15, create a database called 'myapp', set up connection pooling with 20 max connections, and configure it to start on boot." The AI translates this into proper Nix configuration handling the syntax, looking up the right package attributes, structuring the configuration options correctly, managing the boilerplate. You think imperatively, the AI writes declaratively, and Nix verifies the result. This inverts the traditional adoption barrier. Instead of having to learn Nix before you can use it, you can use Nix from day one by expressing what you want in plain language. The weird syntax and verbose boilerplate become the AI's problem, not yours. You get the benefits of declarative, reproducible infrastructure without having to master the tool itself. The same applies to all the declarative tools that have better properties but worse ergonomics: Terraform's HCL, Kubernetes manifests, etc. They're all better than imperative alternatives for reproducibility and verification, but they're harder to learn and more verbose to write. AI bridges this gap: you work imperatively, the AI generates declaratively, and the declarative substrate provides verification. Why This Matters Now: Enter Stochastic Code Generation</h2> Now instead of writing code character by character, we describe what we want and receive entire functions, classes, or modules. This is incredible for productivity, but it introduces new failure modes: Plausible but wrong: AI generates code that looks right but has subtle bugs</li> Inconsistent assumptions: Different sections of AI-generated code may make incompatible assumptions about data types</li> Naming mismatches: Field names, parameter names, method names might be close but not quite right</li> Silent type mismatches: Passing string</code> where int</code> was expected, or vice versa</li> Lost context: AI doesn't always maintain type consistency across the codebase</li> </ul> When a human writes user.email</code>, they remember that user</code> came from a database query two lines ago and has specific fields. When AI generates it, it's making a probabilistic guess based on prior context for that particular session. That guess is often right, but not always. The same flexibility that made Python ergonomic for human-written code becomes treacherous for AI-generated code. The AI can't "just know" the types the way a human author might, just the same way a fresh new grad being thrown a codebase needs time to understand its subtle behavior, the nuances of the language that the codebase exploits / abuses. Agents without that long form persistent experience do the best they can, sample from a distribution of valid completions. TypeScript's Evolution</h3> TypeScript's adoption trajectory shows us a preview of this future. When it launched in 2012, many JavaScript developers saw it as "unnecessary"</a> ceremony. JavaScript was already working fine,why add all this type annotation boilerplate? The tooling was immature. The type definitions for popular libraries were incomplete or wrong. Developers complained about having to write interface</code> declarations for every data structure and explicitly type every function parameter. The turning point came as codebases scaled. When teams grew beyond five people, when code lived longer than six months, when people joined and left organizations, the lack of static checking and other mechanistic verification became a liability. You couldn't rely on humans having perfect context about all the nuances of the codebase. A new hire looks at a function that returns data</code>, has no idea what shape that data has, and makes an incorrect assumption that ships a catastrophic bug into production. TypeScript solved this by making the implicit explicit. Types serve as documentation that the compiler enforces. When someone changes a function signature, every call site gets flagged. When you hover over a variable in your editor, you see exactly what it is. The "unnecessary ceremony" turned out to be essential scaffolding for teams and time scales. Now with AI coding assistants, TypeScript's value proposition has intensified. LLMs generate more accurate code when they have type information to guide them, using types as contracts to ensure correctness. The types that made human collaboration scalable now make human-AI collaboration reliable. Why Runtime Errors Are Worse for AI-Generated Code</h3> Running code to discover errors is orders of magnitude slower than compile-time checking. When an LLM generates code, waits for it to run, encounters a TypeError</code> on line 47, and has to regenerate. Compile errors return in milliseconds. Runtime errors require executing code, potentially setting up test environments, databases, or external dependencies. The AI might need to generate and run code multiple times to catch all the runtime errors that static analysis would have caught immediately. In AI development in particular, runs can be on the order of months. So either you must spend a lot of effort verifying each AI generated piece of code, or you pray that in 2 weeks you wont have a crashed training run. Runtime errors also leave your system in an unknown state. Did the database transaction commit? Did the file get written? Did the message get sent? The AI has no memory of what side effects occurred before the error, making it hard to reason about what needs to be cleaned up or retried. Runtime errors can depend on execution paths, data, and timing. The same AI-generated code might work with one set of inputs and fail with another. It might work in development and fail in production. The LLM might successfully generate code that passes initial tests but contains latent bugs that only appear under specific conditions. Type systems catch these categories of errors unconditionally. In dynamically typed languages, one type error can cascade into many runtime errors. The AI fixes the first error, runs again, hits a second error caused by the same underlying type confusion, fixes that, runs again, hits a third error. With static types, all related errors are caught simultaneously, and fixing the type definition fixes all of them at once. AI coding assistants amplify both the productivity gains of flexible languages and their risks. The New Ergonomics: Flexibility + Safety</h2> This is where formally verified and compiler-verified systems become essential. Languages like Rust, OCaml, Haskell, and even modern TypeScript provide something critical: automated, mechanical verification that generated code is internally consistent. The new ergonomic ideal is this: be loose and viby with intent: ideas, features, specifications, but strict and pedantic with verification. This is where previously "annoying" tools like static analyzers, linters, and type checkers play a crucial role. Good software software written with these agentic tools needs to be self-verifying. Ideally in addition to using a programming language with strong type checking, the codebase itself should be imposing additional contract layers to ensure that new code integrates as expected. Why Pedantic Systems Are Perfect for AI-Assisted Coding</h3> The pairing of AI code generation with strong type systems exploits a fundamental asymmetry in capabilities. LLMs are remarkably good at iterating rapidly through compiler errors without fatigue, pattern matching against type signatures to generate syntactically valid code, and exploring large search spaces of possible implementations. They maintain perfect patience through dozens of compile-fix cycles, never getting frustrated or bored. An LLM will happily regenerate code 20 times to satisfy the borrow checker or fix a type mismatch. But LLMs are comparatively poor at catching subtle semantic bugs that compile correctly, understanding deep business logic and domain invariants, reasoning comprehensively about edge cases and error conditions, or maintaining consistency in intent across a large codebase. These require contextual understanding and judgment that current models lack. This creates a clear division of labor. Strong type systems and compiler verification provide quick, theoretical guarantees about structural correctness, exactly the kind of mechanical feedback that LLMs can iterate against efficiently. The compiler provides immediate, precise feedback that guides the generative process toward valid implementations. The LLM fights through the pedantic mechanical details that would exhaust a human developer. Meanwhile, those same type systems won't catch that you're calculating the discount incorrectly, that you forgot to handle the case where a user account is suspended, or that your algorithm has the wrong complexity for the scale you need. These subtle implementation issues require human review and domain knowledge. This points to what next-generation programming interfaces must solve: surfacing business logic and domain invariants clearly and explicitly, rather than allowing them to be scattered implicitly throughout the codebase. When the critical logic is concentrated and visible, humans can effectively review what matters. The type system details, the mechanical plumbing, the syntactic correctness become increasingly hidden from the human developer, the same way most people don't read the assembly for their programs. Its main role now is as feedback for the LLM during implementing a new set of business logic. Part of this work will also be implementing higher order contract verfication into the codebase so that as new additions are made, conflicts can be surfaced prior to deployement. This suggests a future where programming interfaces have two distinct layers: a dense, type-rich substrate that the LLM interacts with directly, and a higher-level interface where humans specify intent, business rules, and constraints. The human never sees the 40 iterations the LLM took to satisfy the borrow checker. They see the business logic they specified, and tools that help them verify it does what they intended. The type system becomes infrastructure - essential, but largely invisible to the human operator. This isn't just speculation - this pattern is already being deployed in production systems where correctness is life-or-death critical. Real Deployments: Stochastic Generation + Deterministic Verification Today</h2> Dual Verification in Safety-Critical Systems</h3> This pattern of dual-system verification isn't hypothetical, it's already deployed in autonomous vehicles. NVIDIA's DRIVE platform for autonomous vehicles</a> exemplifies this architecture. The system runs two parallel stacks: an end-to-end AI-based autonomous driving system (increasingly powered by models like Alpamayo</a>, which uses vision-language-action models to reason about complex driving scenarios) and a traditional safety verification system. The AI system is generative and stochastic, making probabilistic decisions about steering, acceleration, and navigation based on sensor inputs. It can handle novel situations and reason through edge cases like navigating a traffic light outage, but its decision-making process is fundamentally opaque. The safety system, in contrast, uses traditional formal verification methods that check whether the AI's proposed actions violate safety constraints. The result is exactly the pattern we've been discussing: a stochastic generative system (the AI driver) paired with deterministic verification (the safety stack). The AI explores the solution space creatively, making real-time decisions. The formal verification system checks those decisions against hard constraints such as occupancy, speed limits, and traffic rules. The AI can propose novel solutions to complex problems, but only actions that pass formal verification get executed. This is the template for AI-assisted development writ large. The generative system proposes, the verification system validates, and humans review the semantic correctness at a high level. When your car's autonomy stack makes a decision, you want the same confidence you get from a type-checked program: the mechanical details have been verified, so you can focus on whether the high-level behavior matches your intent. Formal Methods and Theorem Proving</h3> For critical systems, we're seeing interest in even stronger verification: formal methods like dependent types (Idris, Agda), proof assistants (Coq, Lean), and specification languages (TLA+, Alloy). These tools let you specify invariants and properties that must hold, and mechanically verify that your code satisfies them. This was previously seen as too expensive for most software, but when AI can help generate both code and proofs, the cost-benefit calculation changes. The recent breakthroughs in AI-assisted theorem proving demonstrate this isn't hypothetical. Google DeepMind's AlphaProof achieved silver-medal performance at the 2024 International Mathematical Olympiad</a> by proving mathematical statements in Lean. More recently, they achieved gold-medal performance in 2025</a>. These systems train by proving millions of problems, learning from each verified proof to tackle increasingly difficult challenges. Tools like LeanDojo</a> and Lean Copilot</a> now make this accessible for developers. They provide AI-assisted theorem proving that integrates directly into the Lean workflow, with over 210,000 theorems already formalized in mathlib as of 2025. The AI generates proof candidates, the Lean proof assistant verifies them mechanically, and the process iterates until a valid proof is found. This is the same pattern: you specify what properties your system should have (the theorem statement), AI explores the solution space (generating proof candidates), and formal verification ensures correctness (Lean checking each proof). The difference is that instead of catching type errors, you're proving algorithmic correctness, data structure invariants, or protocol safety properties. Imagine: you vibe out the high-level requirements and properties your system must satisfy, AI generates an implementation and proofs that it satisfies those properties, and a proof checker verifies everything mechanically. You get the velocity of vibe coding with the confidence of formal verification. The Cognitive Load Shift</h2> The old model: Writing code: Low cognitive load (flexible, forgiving)</li> Verifying code: High cognitive load (manual review, testing, debugging)</li> </ul> -- or -- Writing code: High cognitive load (fighting to satisfy the compiler, very slow iteration time)</li> Verifying code: Low(er) cognitive load (compiler does much of it automatically, but still some manual review, testing, debugging)</li> </ul> The new model: Writing code: Medium cognitive load (express intent clearly, but let AI handle details)</li> Verifying code: Low(er) cognitive load (compiler does much of it automatically but still some manual review)</li> </ul> This is a fundamental shift in what programming ergonomics means. What "Ergonomic" Means Now</h3> Good software ergonomics used to mean: Minimal ceremony</li> Flexibility</li> Freedom to experiment</li> Low friction for small changes</li> </ul> Good software ergonomics now means: Minimal ceremony for expressing intent</li> Flexibility in approach, rigidity in contracts</li> Freedom to experiment with implementation, strictness in interfaces</li> Low friction for small changes with automated verification</li> </ul> The key insight is that we can have both velocity and safety by separating the stochastic layer (AI generation) from the deterministic layer (type checking and formal verification). Each does what it's good at. Implications for Existing Languages</h2> Today, the choice of tools should be guided by the principles of choosing systems which can enforce correctness and safety, letting LLMs be the interface between the creative high level design decisions (e.g. model architecture choices in a machine learning system) and a deterministic self verifiying implementation. The complaint about Nix flake being too hard to write doesn't make as much sense when the LLM will do it for you and Nix will verify it and all you have to say is "add postgres to my environment". Python's Potential</h3> Python is in an interesting position. It's the language of AI development, but it's poorly suited to AI-assisted application development in its default form. The solution could be more disciplined use of type hints and tools like mypy, Pydantic, and dataclasses. But this only goes so far and requires significant discipline and effort from developers and the LLMs to verify through those tools. Projects like Mojo</a> and efforts to improve Python's performance also point toward a future where Python gets stricter, not looser, because strictness enables better tooling and verification. But what if we didn't retrofit existing languages? What if we designed a language from scratch for this new paradigm? The Compiler's Job: Verification and Translation</h3> The AI compiler should do several things: Translates intent to implementation: Natural language becomes properly structured code</li> Generates verification artifacts: Adds phantom types, lifetime annotations, proofs</li> Enforces contracts: Ensures all requires</code> and ensures</code> clauses are satisfied</li> Iterates on errors: When the verification layer rejects code, the AI regenerates until it passes</li> Optimizes silently: Chooses efficient data structures and algorithms within the constraints</li> Builds internal verification tooling: Adds progressively more verification to the application to test against new additions that validate the semantic correctness the type system can't guarantee</li> </ol> This last point is crucial. Good LLM-assisted design doesn't just generate code that satisfies a type checker - it also generates the verification infrastructure to check semantic properties. When you specify ensure: vip_users_get_at_least(15%)</code> in your discount calculation constraint, the system should generate property-based tests that verify this holds across thousands of randomized inputs. When you declare invariant: suspended_users_cannot_login</code>, the system should generate integration tests that attempt to authenticate suspended users and verify they're rejected. The LLM can generate both the implementation and the verification tooling in parallel, using the same declarative specifications. Your business logic constraints become executable tests. Your invariants become runtime assertions in debug builds and fuzzing targets. The type system catches structural errors, and the generated verification tooling catches semantic errors. This is another advantage of working at the right abstraction level. When humans write tests, we often skip edge cases or forget to test invariants we assume are obvious. When an LLM generates verification tooling from explicit invariant declarations, it can be exhaustive. It doesn't get bored writing the hundredth property test. It will happily generate comprehensive test suites that check every stated constraint from every angle, because constraints are just another kind of specification to translate into code. The human never sees most compiler errors. The AI iterates in the background until the generated code satisfies all the invariants and type constraints. What the human sees is: ✓ Constraint discount_calculation verified ✓ Invariant suspended_users_cannot_login enforced at type level ✓ Session lifetime safety proven ✓ All authentication paths preserve invariants</code></pre> Or, if there's a semantic issue the type system can't catch: ⚠ Warning: discount_calculation may overflow for lifetime_value > $9,999,999,999 Suggest: Add explicit bounds to user.lifetime_value type ⚠ Potential performance issue: authenticate() performs O(n) scan on user table Suggestion: Add index on email column (migrations/add_email_index.sql)</code></pre>Properties of AI-Native Languages</h3> This two-layer architecture enables several key properties: For humans: Write mostly declarative specifications</li> See business logic clearly concentrated</li> Get semantic feedback about domain issues</li> The compiler is not your problem</li> </ul> For LLMs: Clear contracts to satisfy through types</li> Rich type system to iterate against</li> Mechanical verification of correctness</li> Freedom to explore implementation space</li> </ul> For the system: Provably correct by construction</li> Performance optimizations without sacrificing safety</li> Refactoring is automated - change a constraint, AI updates all implementations</li> Testing focuses on business logic, not mechanical correctness</li> </ul> The Gap Today</h3> We're not there yet. Current AI coding tools work with languages designed for humans writing code character by character. But the bones of this vision exist: Rust's type system, Liquid Haskell's refinement types, Dafny's verification, even SQL's declarative nature. What's missing is the integration - a language where the human interface is intent and contracts, the machine interface is rich types and proofs, and AI bridges the gap. Early evidence suggests this approach is viable. Anthropic's experience building a C compiler in Rust with Claude</a> demonstrated exactly this dynamic: the LLM patiently iterated through Rust's strict type system and borrow checker, generating code until it satisfied all the constraints. The compiler's mechanical feedback guided the AI toward correct implementations, catching entire classes of bugs that would have been subtle runtime errors in C. The developers focused on architectural decisions and correctness of the parsing logic, while Claude fought the borrow checker. Conclusion: Embracing the Pedantic</h2> This isn't a compromise or a trade-off. It's a synthesis. We get the benefits of flexible, natural-language-driven development without sacrificing correctness or maintainability. We (humans) write less boilerplate than ever, but the underlying code is verified to be consistent. The definition of ergonomic software development has changed. Languages and tools that felt heavyweight in the era of human-only coding are the lightweight choice in the era of AI-assisted coding. When you didn't write the code yourself, you want as many guarantees as possible. Hoping that an agent writes perfect Python every time is a gamble. The future of programming isn't choosing between velocity and safety - it's using formal systems to verify stochastic processes, and that combination is more ergonomic than either approach alone. An aside: LLMs as an abstraction layer (2/9/26)</h2> Writing assembly is an enlightening experience. Anything is possible, but it's tedious, hard to reason about system state, and errors are easy to make, severe, and difficult to debug (as anyone who has taken ECE 391 at UIUC can attest</a>). The burden of reasoning about system state falls entirely on the programmer. Yet assembly is far preferable to writing raw machine code or having to build an ASIC by hand. The stack machine abstraction built on assembly enables code reuse through strict conventions (like the C calling convention</a>). By imposing limitations through contract—register usage, stack management—two disjoint codebases can be merged to create more complex systems. C adds another abstraction layer with its type system, memory management, and abstract system definition, meaning many developers never need to think about how many bits are in an integer or where a local variable is stored in memory. Objects, methods, and interfaces introduce further contracts that make systems easier to reason about. The operating system provides a common virtual environment for multiple userland programs to interact with hardware concurrently. The GUI offers a graphical language for managing operating system state, creating a more intuitive interface. Each abstraction layer imposes rigid rules on what is allowed that may at first feel limiting, while providing a solid foundation for building higher-order applications. The abstraction layer enforces these rules, ensuring the system remains consistent and predictable. What's missing now is a composable contract system that allows LLMs to expose a higher level of abstraction to developers with the same strong guarantees that existing abstraction layers provide. (Relevant discussion: Software Engineering Past, Present, and Future with Grady Booch</a>) Understanding the Waypoint Transformer Unknown — Sun, 27 Oct 2024 00:00:00 +0000 Waypoint Transformer</h1> The Waypoint Transformer</a> was published at NeuRIPS 2023 by Badrinath et. al. and is a new method for Reinforcement learning via supervised learning (RvS) that builds on the prior Decision Transformer</a> and is conditioned on automatically generated waypoints. Online vs Offline Reinforcement Learning</h3> In reinforcement learning, the agent learns to interact with an environment by taking actions and observing the results. The agent's goal is to maximize the cumulative reward it receives over time. The agent learns by trial and error, exploring the environment and learning from its experiences. There are two large classes of approach to reinforcement learning: online and offline. Online reinforcement learning interacts with the environment in real-time, while offline reinforcement learning learns from collected prior experiences interacting with the environment. Supervised Reinforcement Learning (RvS)</h3> Value-based offline methods tend to attempt to learn a pessimistic value estimate for different states in the state space or state action pairs. This is used to estimate the expected return of a policy. Alternatively, model-based offline RL methods estimate the dynamics of the environment and use it to plan. Typically, complex hyperparameter tuning is required to achieve stable learning. Reinforcement learning via supervised learning (RvS), builds off behavioral cloning as a simple alternative to traditional offline RL. This removes the need for Temporal Difference (TD) learning and value functions and allows offline RL to reuse methods from supervised learning. Typically, the conditioning variable for the policy is based off the return, goal-conditioning, or inverse reinforcement learning, RvS has historically struggled in tasks where the agent must combine multiple sub-optimal training trajectories to achieve a goal. The Waypoint Transformer paper points to two notable examples: reaching specific locations in AntMaze and completing a series of tasks in FrankaKitchen. Here, prior TD methods such as Implicit Q-learning outperform RvS methods. Waypoint Transformer</h2> The Waypoint Transformer introduces a method for generating intermediate goals and more stable proxy rewards that guide the policy towards objectives. Then they use a transformer based RvS method on the generated sub-goals to obtain a policy that learns to follow the waypoints improving performance and stability vs other offline RL methods. Setting</h3> Using the Markov Decision Process (MDP) setting, with states $s_t \in \mathcal{S}$, $a_t \in \mathcal{A}$, unknown dynamics $p(s_{t+1} | s_t, a_t)$ and initial state distribution $p(s_0)$, the agent chooses an action $a_t \sim \pi_{\theta}(a_t | s_{t-k..t}, \Phi_{t-k..t})$, parameterized by $\theta$ and conditioned on a known history of states $s_{t-k..t}$ and a conditioning variable $\Phi_{t-k..t}$ that could encode goals or rewards based on a target global outcome $\omega$. This is distinct from the traditional RL setting where the policy is modeled on $\pi(a_t | s_t)$, as the policy is modeled using a transformer which accepts the past states in a fixed sized context window $k$. The choice of $\omega$ during training is sampled from data. At test time, it is assumed that $\omega$ can be generated or provided by global goal information for a goal-conditioned variant or simply a target reward in the reward-conditioned variant. Waypoints</h3> In offline RL, data typically does not encompass all possible cases that an agent may want to achieve in testing. Consider a infinite dataset $\mathcal{D}$ that is collected by a random behavior policy $\pi_{b}(a_t|s_t)$. When looking to achieve a goal $\omega = s^{(H)}$, the random policy will be suboptimal since actions are selected at random. Then when using a goal conditioned policy $\pi_{G}(a_t|s_t,\omega)$ that is trained using demonstrations from $\mathcal{D}$, the policy will also be suboptimal since $\omega$ is fixed, so $\forall s \in \mathcal{S},$ $\pi_{G}(a_t|s_t,\omega) = \pi_{b}(a_t|s_t)$. So a global goal-conditioned policy cannot be any better than the random behavior policy it was trained on. Instead consider a policy that uses intermediate goals $\pi_{W}(a_t|s_t, \Phi_t)$, $\Phi_t = s_{t+k}$. The paper shows that the probability of choosing an optimal action is higher compared to the longer-horizon goal conditioned policy. $\Phi_t$ also serves as a guide as it guides the policy towards strong intermediate targets to reach the global goal. As long as the selected waypoints are strong ones that lead towards the goal $\omega$, the expectation on policy will be more optimal than behavior cloning. Stitching Waypoints</h4> The ability to compose sequences of otherwise suboptimal trajectories requires finding experiences that are more relevant to achieving subgoals vs the overall goal. The paper uses AntMaze to demonstrate this. They find that only 5% of trajectories using a random policy (this is unclear in the paper) would demonstrate how to cross between a start region and the target region. It is therefore very unlikely to find a trajectory that goes from the start state to the goal state. The policy must stitch together trajectories that start at the start state with trajectories that end at the goal state. By providing waypoints in the stitching regions the policy can be guided to connect the relevant sub-sequences together. Generating Waypoints (Goal-conditioned RvS)</h3> The paper uses a waypoint generator that makes $k$ step ahead predictions of future observations conditioned on $s_t$ and $\omega$. This is parameterized as a neural network that is trained on the same offline dataset $\mathcal{D}$ as the policy using MSE loss. $$ arg\min_{\phi} \sum_{(s_t, \omega) \in \mathcal{D}} || W_{\phi}(s_t, \omega) - s_{t+k} ||^2_2 $$ By doing this you are learning which states $k$ steps ahead you want to visit to reach a goal $\omega$ and then use this to guide the policy. The assumption is that you will have a strong demonstration of the policies to cross $k$ steps from any particular state to other states $k$ steps away. Generating Proxy Rewards (Reward-conditioned RvS)</h3> Prior methods use cumulative reward to-go (CRTG) - a dynamic estimate of the reward to go or average reward-to-go (ARTG) - a static estimate of the reward to go as proxy rewards for the policy. However, using these conditioning variables has drawbacks: the variance of cumulative reward-to-go is high and the bias of the average reward-to-go is high. Instead of using a learned value function like in TD methods, this paper adds a reward waypoint network to estimate both cumulative and average reward-to-go conditioned on $s_t$ and $\omega$ using $\mathcal{D}$. They claim that modeling both CRTG and ARTG addresses the high bias of ARTG and the high variance of CRTG in the same way that prior methods like REINFORCE</a> do. Policy Transformer</h3> The architecture for the waypoint transformer is based on GPT-2. The policy is conditioned on the past $k$ states and the waypoints (either the goals or rewards) $\Phi_{t - k..t}$ which are generated by the waypoint network. The policy transformer is trained using negative log likelihood loss based on data sampled from $\mathcal{D}$. During this process, the waypoint network is fixed. Unlike decision transformers, the waypoint transformer is not conditioned on past actions. Experiments</h2> The proposed method is evaluated on two environments that come with many suboptimal demonstrations in the goal-conditioned case: AntMaze and FrankaKitchen. FrankaKitchen specifically has no end to end demonstrations available. For each of these environments, the paper uses goal conditioning where $\omega = s_{target}$ and constructs intermediate waypoints using the goal waypoint network. For reward-conditioned tasks they use Gym-MuJoCo. For a plurality of evaluated tasks, waypoint transformers outperform decision transformers and other offline RL methods. However there are some cases where TD still outperforms the waypoint transformer or that waypoint transformer simply matches the performance of behavior cloning. The authors analyze the behavior of the waypoint transformer on AntMaze, they find that WT is much more effective at reaching the goal state than a globally conditioned policy and completes the task faster. When using $k = 30$ vs. $k = 0$, the performance is 2.2x worse. On reward conditioned tasks the authors analyze the behavior of the waypoint transformer on Hopper-v2. They find that the standard deviation of CRTG grows slower than other methods. WT is also more robust to the choice of seed than other methods. Interestingly in the appendix, they evaluated using manually selected waypoints and found that WT outperforms manual waypoints. However the manual waypoints are still better than no waypoints and the difference seems to come down to the density of waypoints selected. The manual waypoints are much coarser than the waypoints selected by the waypoint network. Why This Matters</h3> The real usefulness of this method is to be able to collect a lot of partial demonstrations of relevant trajectories, then allow the waypoint network guide the policy to compose them together to achieve a goal in an environment with sparse rewards where traditional RL methods would struggle or would require much higher quality data. RvS is a compelling method for RL since it does not require learning a value function which is incredibly sensitive to initialization and requires a lot of data to learn. The issue with prior RvS methods is that they rely on the quality of the demonstrations to be able to learn a good policy. Behavior cloning and imitation learning methods alone are unable to utilize partial demonstrations as well, requiring demonstrations that fully explain how to achieve a goal. This makes data collection incredibly expensive and time consuming particularly when goal and start states are not fixed. Waypoint transformers demonstrate a method to learn from partial demonstrations and compose them together to achieve a goal. However, waypoint transformers are a method designed to handle degenerate cases. In cases where demonstrations are complete, waypoint transformers are not necessary and their performance will be similar to behavior cloning or decision transformers. This paper focuses on spatial composability and reward interpolation, it is unclear how well waypoint transformers are able to compose over other dimensions such as skill chaining. Building CLIP from Scratch to Classify Pokemon Unknown — Mon, 07 Oct 2024 00:00:00 +0000 Building CLIP from Scratch to Classify Pokemon</h1> Prior deep learning approaches to performing image classification frame the problem as given a dataset of image, label pairs, learn a mapping between the image space and the label space using a neural network (MLP, CNN, etc.). Here the image space is typically a CxHxW dimensional space where C is the number of channels, H and W are the height and width of the input image. Labels may have semantic meaning to us as humans, but are presented to the model simply as one-hot encoded vectors in a fixed sized N-D space where N is the number of possible different labels that can be seen in the dataset. Each dimension of the label space is assigned a distinct possible label, and the models output in that any particular dimension represents the models confidence that the image is of that class. Extremely good performance on classification tasks can be achieved using this problem framing and a good choice of model architecture. However, this framing has drawbacks when trying to move out of narrow independent and identically distributed settings, such as classification of images that are of a class not seen before or dealing with slightly differently formed labels. In such cases, the model is unaware of the existence of anything other than the N classes it was designed to decide between. Even if it was, it would not be able to represent a novel class due to its fixed sized output and the assigned semantic meanings to each dimension. More recently, self-supervised methods have emerged which use simple scalable training tasks to create models that can easily be repurposed for a number of different tasks. Many of these methods avoid the use fixed sized label spaces instead looking to embed representations of different modalities of data in a common embedding space. Distance in this embedding space represents “sameness”. These models look to therefore project tuples of related data into the same area in embedding space. Unseen labels or classes can be projected into this embedding space just as easily as seen data, so even if the model has not seen that exact label before, it its embedding should be close to similar seen labels and consequently their corresponding images. One of these methods is Contrastive Language-Image Pre-training (CLIP). CLIP looks to take image and text pairs such as captions for an image or alt-text and estimate how related they are by this projection into a common embedding space. As opposed to “traditional” classification approaches, CLIP is not attempting to solve the classification problem directly. It instead looks to maximize the cosine similarity between correct image text pairs in the joint embedding space and minimize the similarity between incorrect pairs. CLIP can then be repurposed for classification by giving the model the choice between a number of potential captions (or labels) for an unseen image. The caption with the highest cosine similarity can be considered the class, leading to what is known “open world” object recognition. In this tutorial, we will learn how to create our own CLIP model and use it to classify images of Pokemon. The CLIP Model</h2> The CLIP model consists of a text encoder and an image encoder. Since the ultimate goal is to be able pair image embeddings with their corresponding text embeddings, these two models are trained together to maximize the pairwise cosine similarities between corresponding image and text embeddings and conversely minimize the cosine similarity between image and text embeddings from different pairs. class CLIP(nn.Module): def __init__(self, emb_dim, vit_width, img_size, patch_size, n_channels, vit_layers, vit_heads, vocab_size, text_width, max_seq_length, text_heads, text_layers): super().__init__() self.image_encoder = ImageEncoder(vit_width, img_size, patch_size, n_channels, vit_layers, vit_heads, emb_dim) self.text_encoder = TextEncoder(vocab_size, text_width, max_seq_length, text_heads, text_layers, emb_dim) self.temperature = nn.Parameter(torch.ones([]) * np.log(1 / 0.07)) self.device = torch.device("cuda" if torch.cuda.is_available() else "cpu") def forward(self,image,text, mask=None): I_e = self.image_encoder(image) T_e = self.text_encoder(text, mask=mask) # scaled pairwise cosine similarities [n, n] logits = (I_e @ T_e.transpose(-2,-1)) * torch.exp(self.temperature) # symmetric loss function labels = torch.arange(logits.shape[0]).to(self.device) loss_i = nn.functional.cross_entropy(logits.transpose(-2,-1), labels) loss_t = nn.functional.cross_entropy(logits, labels) loss = (loss_i + loss_t) / 2 return loss</code></pre> If you don’t know what text or image encoders are, you might want to follow a more bottom-up CLIP tutorial that first develops these concepts: https://medium.com/correll-lab/building-clip-from-scratch-68f6e42d35f4 Text Encoder</h3> For the text encoder in CLIP we use the standard transformer architecture. However we want to embed features in the joint vision-text embedding space. Therefore we have an extra set of parameters nn.Parameter(torch.randn(width, emb_dim))</code>. In the forward function, the text features are embedded in the joint space by getting the dot product of the features and the learned projection divided by the normalized dot product. class TextEncoder(nn.Module): def __init__(self, vocab_size, width, max_seq_length, n_heads, n_layers, emb_dim): super().__init__() self.max_seq_length = max_seq_length # Maximum length of input sequence self.encoder_embedding = nn.Embedding(vocab_size, width) # Embedding Table self.positional_embedding = PositionalEmbedding(width, max_seq_length) self.encoder = nn.ModuleList([TransformerEncoder(width,n_heads) for _ in range(n_layers)]) # learned proj of image to embed self.projection = nn.Parameter(torch.randn(width, emb_dim)) def forward(self, text, mask=None): # Text Embedding x = self.encoder_embedding(text) # Positional Embedding x = self.positional_embedding(x) # Transformer Encoder for encoder_layer in self.encoder: x = encoder_layer(x, mask=mask) # Takes features from the EOT Embedding x = x[torch.arange(text.shape[0]),torch.sub(torch.sum(mask[:,0],dim=1),1)] # joint multimodal embedding if self.projection is not None: x = x @ self.projection x = x / torch.norm(x, dim=-1, keepdim=True) return x</code></pre>Image Encoder</h3> For the image encoder we use the standard vision transformer architecture. Similar to the text encoder, we have an extra set of parameters nn.Parameter(torch.randn(width, emb_dim))</code>, the forward function will embed the image features in the joint embedding space by taking the dot product of the features and the learned projection divided by the normalized dot product. class ImageEncoder(nn.Module): def __init__(self, width, img_size, patch_size, n_channels, n_layers, n_heads, emb_dim): super().__init__() assert img_size[0] % patch_size[0] == 0 and img_size[1] % patch_size[1] == 0, "img_size dimensions must be divisible by patch_size dimensions" assert width % n_heads == 0, "width must be divisible by n_heads" self.n_patches = (img_size[0] * img_size[1]) // (patch_size[0] * patch_size[1]) self.max_seq_length = self.n_patches + 1 # Patch Embedding self.linear_project = nn.Conv2d(n_channels, width, kernel_size=patch_size, stride=patch_size) # Classification Token self.cls_token = nn.Parameter(torch.randn(1, 1, width)) self.positional_embedding = PositionalEmbedding(width,self.max_seq_length) self.encoder = nn.ModuleList([TransformerEncoder(width,n_heads) for _ in range(n_layers)]) # learned proj of image to embed self.projection = nn.Parameter(torch.randn(width, emb_dim)) def forward(self,x): # Patch Embedding x = self.linear_project(x) x = x.flatten(2).transpose(1, 2) # Positional Embedding x = torch.cat((self.cls_token.expand(x.size()[0], -1, -1),x), dim=1) x = self.positional_embedding(x) # Transformer Encoder for encoder_layer in self.encoder: x = encoder_layer(x) # Takes Class Tokens x = x[:, 0, :] # joint multimodal embedding if self.projection is not None: x = x @ self.projection x = x / torch.norm(x, dim=-1, keepdim=True) return x</code></pre>Training</h3> The training process consists of providing image, caption pairs from the dataset. CLIP uses contrastive loss to train the model. Since we are looking to maximize the scaled pairwise cosine similarities between the image and text embeddings along the diagonal where the text and image embeddings are correctly paired, we can use cross entropy loss across the rows and columns with psuedo-labels corresponding to the index of the embedding. This is the same as evaluating $n$ distinct text -> image estimates and $n$ image -> text estimates concurrently. The model loss is the mean loss between the text and image cross entropy loss. labels = torch.arange(logits.shape[0]).to(self.device) # Label for row/column i is i (i.e. the index of the correct other half of the pair) loss_i = nn.functional.cross_entropy(logits.transpose(-2,-1), labels) loss_t = nn.functional.cross_entropy(logits, labels) loss = (loss_i + loss_t) / 2</code></pre>Dataset</h3> For this tutorial we will use Faith Aykon</a>'s Mini-Pokemon dataset</a>, hosted on HuggingFace (this requires datasets==2.21.0</code>). This dataset consists of 280 examples in a 210/70 train/test split. The full dataset has 7000 images but as such takes much longer to train, though the code can be trivially modified to use the full dataset We will perform a number of modifications to this dataset to make it more suitable to training for CLIP. from torchvision.transforms import v2 class Pokemon(Dataset): def __init__(self, train=True): # Download the dataset from HuggingFace, use the mini split (change "mini" to "full" for the full dataset) self.dataset = load_dataset("fcakyon/pokemon-classification", "mini", trust_remote_code=True) # Image preprocessing self.transform = v2.Compose([ v2.Resize((128, 128)), v2.ToTensor() ]) if train: self.split = "train" else: self.split = "test" self.label_names = self.dataset[self.split].features["labels"].names self.caption_options = ["An image of {0}", "A {0}", "A photo of {0}", "A {0} in a photo", "A picture of {0}", "A {0} image"] self.captions = { i: f"An image of a {l}" for i, l in enumerate(self.label_names) } self.labels = { i : l for i,l in enumerate(self.label_names) } def __len__(self): return self.dataset.num_rows[self.split] def __getitem__(self,i): img = self.dataset[self.split][i]["image"] img = self.transform(img) caption_template = np.random.choice(self.caption_options) caption_text = caption_template.format(self.labels[self.dataset[self.split][i]["labels"]]) cap, mask = tokenizer(caption_text) mask = mask.repeat(len(mask),1) return {"image": img, "caption": cap, "mask": mask, "text": caption_text, "label": self.dataset[self.split][i]["labels"]}</code></pre>Image Preprocessing</h4> We define a transformation pipeline which gets applied to each image using self.transform = v2.Compose([ v2.Resize((128, 128)), v2.ToTensor() ])</code></pre> There is not too much data augmentation needed for simple cases, therefore we just resize the input image to a reasonable size. Text Preprocessing</h4> The original dataset is set up for more traditional classification approaches, i.e. some class label for each image which is an int</code> representing the index of the 1 in a one-hot encoded form of the label. Since CLIP uses text and not one-hot encoded vectors for the “labels”, we need to generate them. The critical information is the type of Pokemon in the image. However, there are many ways in natural language to convey the same information and we want to be robust to phrasing as it will help our classifier be more robust later on. Therefore, we include a number of caption templates that phrase the label in many semantically similar ways. When retrieving a new image, a label pair is pulled from the dataset, this code will choose one of the caption templates to create a caption containing the label text. class Pokemon(): def __init(self, ...): ... self.caption_options = ["An image of {0}", "A {0}", "A photo of {0}", "A {0} in a photo", "A picture of {0}", "A {0} image"] def __getitem__(self, i): ... caption_template = rng.choice(self.caption_options) caption_text = caption_template.format(self.labels[self.dataset[self.split][i]["labels"]]) </code></pre>Tokenization</h4> Transformer models do not work directly on text, instead they use a numerical representation of characters (tokens). In this example we use a trivial tokenization scheme UTF-8. With the UTF-8 encoding the max vocabulary size is 256 since we are direct mapping from characters. For larger desired context sizes, other tokenization schemes with greater vocabulary sizes may be desired. The tokenizer delimits the input string with start and end tokens, reserved values that denote the limits of the input. Since the input to the transformer is fixed size, the input tensor is padded to the full width of the input. Finally a mask is created to denote that padded inputs should be ignored. def tokenizer(text, encode=True, mask=None, max_seq_length=32): if encode: out = chr(2) + text + chr(3) # Adding SOT and EOT tokens out = out + "".join([chr(0) for _ in range(max_seq_length-len(out))]) # Adding Padding out = torch.IntTensor(list(out.encode("utf-8"))) # Encoding Text mask = torch.ones(len(out.nonzero())) mask = torch.cat((mask,torch.zeros(max_seq_length-len(mask)))).type(torch.IntTensor) else: out = [chr(x) for x in text[1:len(mask.nonzero())-1]] out = "".join(out) mask = None return out, mask</code></pre> These tokenzied forms of the captions are pre-calculated as part of the dataset. cap, mask = tokenizer(caption_text)</code></pre> Since the mask will be applied to the attention scores ($max_seq_len x max_seq_len$), it needs to be repeated to be applied to each row. mask = mask.repeat(len(mask),1)</code></pre> Therefore for each entry in the dataset we have the following information {"image": img, "caption": cap, "mask": mask, "text": caption_text, "label": self.dataset[self.split][i]["labels"]}</code></pre>Example</h5> image.shape: torch.Size([3, 128, 128]) caption.shape: torch.Size([32]) mask.shape: torch.Size([32, 32]) text: "A Alakazam image" caption(tokenized): tensor([ 2, 65, 32, 112, 104, 111, 116, 111, 32, 111, 102, 32, 65, 108, 97, 107, 97, 122, 97, 109, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], dtype=torch.int32) mask: tensor([[1, 1, 1, …, 0, 0, 0], [1, 1, 1, …, 0, 0, 0], [1, 1, 1, …, 0, 0, 0], …, [1, 1, 1, …, 0, 0, 0], [1, 1, 1, …, 0, 0, 0], [1, 1, 1, …, 0, 0, 0]], dtype=torch.int32)</code></pre>Hyperparameters</h4> These are the parameters I used for training on a 3080Ti. The notebook contains these parameters and the seed I used. Some modifications to the batch size might be needed if training on smaller GPUs. emb_dim = 32 vit_width = 9 img_size = (128,128) patch_size = (64,64) n_channels = 3 vit_layers = 3 vit_heads = 3 vocab_size = 256 text_width = 32 max_seq_length = 32 text_heads = 8 text_layers = 4 lr = 1e-3 epochs = 1500 batch_size = 1024</code></pre>Training Loop</h4> device = torch.device("cuda" if torch.cuda.is_available() else "cpu") print("Using device: ", device, f"({torch.cuda.get_device_name(device)})" if torch.cuda.is_available() else "") model = CLIP(emb_dim, vit_width, img_size, patch_size, n_channels, vit_layers, vit_heads, vocab_size, text_width, max_seq_length, text_heads, text_layers).to(device) optimizer = optim.Adam(model.parameters(), lr=lr) best_loss = np.inf for epoch in range(epochs): for i, data in enumerate(train_loader, 0): img, cap, mask = data["image"].to(device), data["caption"].to(device), data["mask"].to(device) loss = model(img,cap,mask) optimizer.zero_grad() loss.backward() optimizer.step() # Saves model if it performed better than the previous best print(f"Epoch [{epoch+1}/{epochs}], Batch Loss: {loss.item():.3f}") if loss.item() <= best_loss: best_loss = loss.item() torch.save(model.state_dict(), "clip_pokemon4.pt") print("Model Saved.")</code></pre>Testing Performance</h3> We can evaluate how well our model is at associating image text pairs. We start by creating a spanning set of captions for the different possible labels using one a slightly different caption form from those seen in training (ex. ”An image of a Pikachu”). This was actually done as part of the dataset construction: self.captions = { i: f"An image of a {l}" for i, l in enumerate(self.label_names) }</code></pre> Each of these potential captions is tokenzied using the tokenizer and fed to the text encoder and a batch of images from the test set are fed into the image encoder. We then calculate the cosine similarity between the text and image embeddings and run softmax to get probabilities that any particular label is the best pairing for a particular image. We can then match these predicted captions with the true label to determine if the model was correct or not. # Loading Best Model model = CLIP(emb_dim, vit_width, img_size, patch_size, n_channels, vit_layers, vit_heads, vocab_size, text_width, max_seq_length, text_heads, text_layers).to(device) model.load_state_dict(torch.load("clip_pokemon4.pt", map_location=device)) # Getting dataset captions to compare images to text = torch.stack([tokenizer(x)[0] for x in test_set.captions.values()]).to(device) mask = torch.stack([tokenizer(x)[1] for x in test_set.captions.values()]) mask = mask.repeat(1,len(mask[0])).reshape(len(mask),len(mask[0]),len(mask[0])).to(device) correct, total = 0,0 with torch.no_grad(): for data in test_loader: images, labels = data["image"].to(device), data["label"].to(device) image_features = model.image_encoder(images) text_features = model.text_encoder(text, mask=mask) image_features /= image_features.norm(dim=-1, keepdim=True) text_features /= text_features.norm(dim=-1, keepdim=True) similarity = (100.0 * (image_features @ text_features.T)).softmax(dim=-1) _, indices = torch.max(similarity,1) correct += torch.sum(indices==labels) total += len(labels) print(f'\nModel Accuracy: {100 * correct // total} %')</code></pre> Using my training settings and seed, I was able to achieve 87% accuracy on the Pokemon-mini dataset. This is not really representative for C LIP’s power, as the dataset we have used for training here is very small. Using a CNN would actually be the preferred approach here. Yet, for very large datasets CLIP has outperformed previous CNN model. Zero-shot Classification</h3> We can reuse our CLIP model to perform the classification task now. First we generate a list of possible labels. These will just be names of different types of Pokemon found in the dataset (ex. ”Pikachu”). We then tokenize each potential label and feed them to the text encoder. We also feed an unlabeled image to the image label. The CLIP model will return the similarities between each potential label and the image based on the training it had seen before. Note that we never just provide the label alone as a text pairing during training, but we do provide various different captions which all share the label word within them. This demonstrates how, because of our pre-training, we are robust to unseen label forms and yet can correctly associate the image with the correct label. # Loading Best Model model = CLIP(emb_dim, vit_width, img_size, patch_size, n_channels, vit_layers, vit_heads, vocab_size, text_width, max_seq_length, text_heads, text_layers).to(device) model.load_state_dict(torch.load("clip_pokemon4.pt", map_location=device)) # Captions to compare images to class_names = test_set.label_names class_text = [f"{l}" for l in class_names] text = torch.stack([tokenizer(x)[0] for x in class_text]).to(device) mask = torch.stack([tokenizer(x)[1] for x in class_text]) mask = mask.repeat(1,len(mask[0])).reshape(len(mask),len(mask[0]),len(mask[0])).to(device) idx = 12 img = test_set[idx]["image"][None,:] plt.imshow( img[0].permute(1, 2, 0),) plt.title(test_set[idx]["text"]) plt.show() img = img.to(device) with torch.no_grad(): image_features = model.image_encoder(img) text_features = model.text_encoder(text, mask=mask) image_features /= image_features.norm(dim=-1, keepdim=True) text_features /= text_features.norm(dim=-1, keepdim=True) similarity = (100.0 * image_features @ text_features.T).softmax(dim=-1) values, indices = similarity[0].topk(5) # Print the result print("\nTop predictions:\n") for value, index in zip(values, indices): print(f"{class_names[int(index)]:>16s}: {100 * value.item():.2f}%")</code></pre> You can find a notebook with the code from this tutorial here</a> All Recommendation Engines Should Follow Twitter's Example on Transparency Unknown — Sat, 01 Apr 2023 00:00:00 +0000 This week has been weird to say the least. We have fringe figures in the artificial intelligence community publishing opinions in Time Magazine on the need to take violent action to stop the propagation of large language models</a>, but I thought the most important story was Elon Musk and Twitter releasing the source code for their Tweet recommendation system</a>. I'm going to keep referring to this thing as a system or engine. I refuse to call it an algorithm. There are no strong guarantees associated with these systems, they mostly boil down to a collection of heuristics. Calling them an algorithm bastardizes the meaning of the term. </details> There's a lot of reasons to be tired of hearing about Twitter and Elon Musk. Twitter is a navel-gazy self important subculture full of "niche internet celebrities" being toxic to each other in one way or another. And Elon oscillates from being out of touch to down right unhinged depending on the hour. However, Twitter and other social media platforms for many, and particularly many who occupy other places of influence in society, serves as their primary lens on the state of the world. Many measure importance of issues, people, ideas etc. based on the traction they garner on these platforms. Therefore, it matters how and why some things are widely promoted and somethings are suppressed. When Twitter released the source, Elon put out the following Tweet. Most of the recommendation algorithm will be made open source today. The rest will follow. Acid test is that independent third parties should be able to determine, with reasonable accuracy, what will probably be shown to users. No doubt, many embarrassing issues will be… https://t.co/41U4oexIev</a>— Elon Musk (@elonmusk) March 31, 2023</a></blockquote>

Do We Still Need Agile?

Humanities in SV

Jujutsu is the GOAT but I have no idea how to teach people about it

We Need Societal Scaling Laws

SWE Automation Is the Killer App

The Definition of Good Software Ergonomics Has Changed

The Old Ergonomics: Flexibility vs. Safety</h2> Python/JS: Maximal Expressiveness</h3> For decades, languages like Python, Ruby, and JavaScript defined "ergonomic" programming. They clearly made design decisions prioritizing:</p>

Python/JS: Maximal Expressiveness</h3> For decades, languages like Python, Ruby, and JavaScript defined "ergonomic" programming. They clearly made design decisions prioritizing:</p>

The Deal We Made with the Devil</h4> But this flexibility came with costs that we grudgingly accepted:</p>

Real Deployments: Stochastic Generation + Deterministic Verification Today</h2>

The Cognitive Load Shift</h2> The old model:</p> Writing code</strong>: Low cognitive load (flexible, forgiving)</li>

What "Ergonomic" Means Now</h3> Good software ergonomics used to mean:</p>

Properties of AI-Native Languages</h3> This two-layer architecture enables several key properties:</p> For humans:</strong></p>

Understanding the Waypoint Transformer

Building CLIP from Scratch to Classify Pokemon

Image Preprocessing</h4> We define a transformation pipeline which gets applied to each image using</p>

All Recommendation Engines Should Follow Twitter's Example on Transparency