Every spring, we get a flood of stories about college graduation ceremonies -- typically full of tut-tutting about inappropriate behavior or inappropriate speech -- always presented as synecdochical of all of higher ed. Oh sure sure, there’s often the odd tale of triumph: someone’s service dog gets a diploma; someone in their 70s finishes medical school. But mostly these stories serve to reinforce other, more dour narratives about college students -- unprepared, entitled, intolerant -- and about college itself -- irreverent, irrelevant.

This year, despite a brief attempt to gin up controversy surrounding NYU’s selection of Jonathan Haidt as its commencement speaker – sigh, yet another tale of "the coddling of the American mind" – the coverage has focused on the chorus of boos whenever speakers heralded this glorious "AI" future students are poised to step into.

And perhaps it’s a little ironic that this graduating class, a group that we've been told time and time again has spent the last four years using ChatGPT to cheat their way through college, would display such sour sentiment towards "AI." But as most commencement speakers seem duty-bound to repeat, graduation marks the entry into adulthood; it is "the beginning of your life"; "the future is now" – that sort of thing. And just these students are now officially adults, they’re being told a very different story: that there really is no future. There are no jobs. And whatever thing they might have learned to do or learned to love in college, whatever career they might have believed they were preparing for, "AI" is going to destroy all of that.

No wonder they boo.

Here these young people are, having just done everything they were told to do to be successful. They got good grades in high school. They did all the extracurriculars. They scored sufficiently well on the SATs. They were admitted into college – maybe not their first choice, but they got in somewhere, and dammit, they stuck it out for four maybe five years. They completed all the coursework, sat through all the Zoom lectures and the in-person lectures and through all the AI-proctored and in-person exams. They checked all the digital boxes, submitted their homework through the LMS portal's plagiarism-checker, responded to at least two classmates posts on the LMS discussion boards. They used "AI," fine sure but fuck it, because the technology sure used them too. They handed key decisions over to algorithms – not just what YouTube videos to watch while they scrolled through the digital textbooks but what courses to take so that the whole effort of the degree was manageable. Because along the way, the majority of them also worked at one or more jobs; and the majority of them went into debt.

They were promised that if they did all this, if they received a bachelor's degree, then they'd be able to get a good job and make a decent living to support themselves and support their families. But now, even before their diplomas are in hand, they're discovering that the promise was a lie. There aren't any jobs for college graduates, they're being told. All this is supposedly thanks to "AI," a technology that these students know probably better than any other group out there, churns out the most laughably banal bullshit.

The whole "digital natives" trope is undoubtably hogwash -- the ridiculous idea that young people, by virtue of being born into a world of computational machinery are more adept at its manipulation. These students have spent their whole lives being taught, cajoled, entertained, and surveilled by computers and algorithms -- in and out of the classroom. (But importantly, in.) But they recognize now -- if they hadn't already -- as rejection letter after rejection letter hits their email inbox, that they're being spurned by this same machinery that they’re supposedly most in tune with. “Those who live by electronics, die by electronics. Sic semper tyrannis,” as Kurt Vonnegut wrote in Player Piano -- not really a message you want to hear on graduation day, a ritual that’s meant to mark beginnings and possibilities. But nor do you want to hear someone hyping the very technology that has just sent you some stale, autogenerated text denying you yet another job interview.

All mention of “AI” does is remind them of the political economy from which this monstrous extractive machine has emerged, remind them that their options and their opportunities appear to be utterly foreclosed.

They have no choice. They have no agency. They must comply. The future is written, these smug (and affluent) "AI" boosting graduation speakers have the audacity to tell these students. Just suck it up. Deal with it.

It's this sneering attitude, I'd argue, that is driving so much of the pushback against "AI" and against ed-tech -- it’s Cory Doctorow’s “enshittification” plus a lot of infantilization. People are sick of being told that these technologies are inevitable, particularly when they can see, because they have experienced, the damage they are causing (all while these technologies are generating the wild profits for a small handful of billionaires).

Welcome to adulthood, the graduation speakers always say. But now, they echo the messaging that Silicon Valley has churned out for years now: you'll have to learn to enjoy the digital immiseration because there's nothing you can do about it. There's no turning back, no getting rid of computers, no option for analog, no alternative.

Students boo because they know it's bad. They boo because they know it's wrong – wrong ethically, wrong politically, wrong historically, wrong economically, wrong environmentally.

It's bad. It's wrong. And it's also untrue, all these pronouncements about technological inevitability. The future is not yet written. No doubt, much like the "digital native" trope, these tales do sadly seem to provide comfort and cover (and conversation-ending cliche) for those whose jobs still entail spit-shining the gadgetry.

In the past, Americans mostly haven't minded this story, because Americans sure love their shiny gadgets. But more and more, I think, they've come to recognize that the shininess barely masks the shit. The promises of techno-solutionism – that any sufficiently complicated problem can be magically fixed with technology (not quite what Arthur C. Clarke said, but close enough) – is less and less believable.

The powerful forces of industry and government (and yes schools) seem keen to strip people of their agency, to prevent them from having any say in the conditions of their work, leisure, learning, life. And not just keen but absolutely thrilled to do so.

But the growing pushback against "AI," and the growing pushback against ed-tech more generally, is not simply a rejection of technology. These efforts are, as Astra Taylor and Saul Levin recently argued in The Guardian, a rejection of the profoundly anti-democratic practices that have pushed technologies into all aspects of our lives without our consent and often in the face of our outright opposition. These technologies have been marketed to us as solutions to all sorts of social problems -- and have done so, in no small part, by bypassing and undermining the very public sphere in which debate and discussion can take place: schools, libraries, the arts, the media.

The adoption of education technology, "AI" or otherwise, has been anti-democratic in practices both big and small. Despite all the talk of progressive education and ed-tech, it has been experienced as something else entirely. Throughout the country for the past few decades Gates (via the Gates Foundation), other billionaire philanthropists, and giant companies have shaped education funding and policy through a combination of technology and testing.

At one point, perhaps, people were willing to welcome devices into schools, into the classroom. They believed the stories, not just that "this is the future," but that future meant something better for everyone. “Access” signaled equality. But as the tech billionaires have embraced authoritarianism and inequality, and as their apocalyptic rhetoric about not just the "end of work," but quite literally the end of the world grows louder and louder -- all while they amass more wealth than anyone in history -- it is quite apparent that their promises about the future do not include us. Their vision of future does not make any space or allowance for our children to choose their own futures.

In their essay in The Guardian, Taylor and Levin chastise the liberals and progressives who have recently been vocal in their criticism of datacenter opponents. (It's an analysis that can readily be mapped to education technology, where many people still insist that their politics are progressive, all while wrapping themselves in the same rhetoric as technology's most authoritarian boosters, insisting there's nothing people can do about the material conditions of their lives other than obey obey obey.) "As usual, ordinary people are ahead of their leaders," Taylor and Levin write, with a nod to Antonio Gramsci. "The remarkable organic growth of the datacenter resistance movement across geographies, economic interests and ideology reflects the myriad harms that come with AI infrastructure and growing anger at the tech elite. The tremendous energy unleashed by these fights, and their sensible and unifying demands, have the potential to form the foundations of a new and powerful populist coalition, one poised to help define a working-class agenda that meets this moment and resonates with disaffected voters. This excellent organizing should be cultivated rather than dismissed."

How do we meet this moment with disaffected students? Probably not by insisting that they need to suck it up and keep using Canvas, eh?

Elsewhere:

"Even If You Hate AI, You Will Use Google AI Search," reads the headline in Wired on the changes Google plans to make to Search. (Spoiler alert: they're gutting it.) This is precisely that anti-democratic impulse that I talk about above, an impulse that permeates the tech industry and its marketing: the language of inevitability and dismissive attitude towards any sort of resistance – "this sucks but you have no choice but go along with it." More via Garbage Day: “An internet after search engines.”

“How Deepfakes Tore a High School Apart” by 404 Media’s Samantha Cole. “Video shows ICE violently arresting Oregon farm workers and using facial recognition” via The Guardian. These are how many communities are experiencing "AI," and if you are advocating for more "AI" in schools, I hope you can recognize that this is what people hear you're calling for.

“What Schools Are Forgetting in Their Race to Embrace A.I.” by David Wallace-Wells in The New York Times.

“My Son’s Math Homework Is Essentially Just Pokémon” writes Will Oremus

“A Technical Deep Dive Is Not a Crisis Response” -- Phil Hill on Instructure's response to its recent data breach.

“The Surveillance Classroom” by Andrew Cantarutti. 404 Media’s Joseph Cox” reports on how “Researchers Wanted Preschool Teachers to Wear Cameras to Train AI.”

“Sycophantic AI decreases prosocial intentions and promotes dependence” by Myra Cheng et al.

“A Year Ago, Experts Worried About NAEP’s Future. Now, the Test is Expanding” reports The 74. Those who are advocating the expansion of testing right now are just wildly out-of-touch. You cannot separate testing and technology, and the latest anti-ed-tech efforts are part of an ongoing resistance to the ways in which all aspects of school have bent towards the demands of standardized testing. "We're going to test your kids even more" is not a winning political message, certainly not if you're interested in democratic educational practices.

Brian Merchant writes about the unionization of IT workers in the University of California system.

The American Academy of Pediatrics has issued new guidance on the importance of recess -- “for the first time in 13 years," as the AP notes. Everyone needs to take more breaks. Everyone needs time and space for play, no matter your age.

Today's bird is the vulturine guinea fowl, the largest bird in the guinea fowl species. Guinea fowls all have unfeathered heads, but the particular shape of the vulturine guinea fowl's bald head and neck is, well, vulture-like. The bird – both male and female – has a cobalt-blue body with long black and white feathers. There are far too many websites IMHO that seem to sell the birds (which breeders promise do well in captivity), and I guess the elimination of Google Search will take care of that online business. Wheeee.

Thanks for reading Second Breakfast.

“A woozle effect…occurs when frequent citation of previous publications that lack evidence misleads individuals, groups and the public into thinking or believing there is evidence, and non-facts become urban myths and factoids.”

The 13 circuits of the U.S. federal courts of appeals operate with a fair amount of independence, including their typographic choices. I was reminded of this today while reading the aforelinked decision from the Ninth Circuit in Epic v. Apple, because the Ninth Circuit sets their decisions in Times New Roman — a font that came up back in December in the context of the Trump State Department.

Long argument short, Times New Roman isn’t bad, but it isn’t good. It is the median choice. But most of the circuit courts use it: the Third, Sixth, Eighth, Ninth, Tenth, and Eleventh. It could be worse: the First and Fourth not only use Courier New (the worst version of Courier, so of course it’s the one Microsoft shipped with Windows), but fully justify their text — contrary to the nature of a monospaced font. It could be better: the Second and Seventh use Palatino. (Note how much better that Seventh Circuit decision looks than the Second’s, with its wider margins creating a narrower column of text.)

But it can be much better. The Fifth Circuit was long typographically superior to its peers, using Century Schoolbook — a highly legible font with great tradition and the right vibe. But in 2020, the Fifth Circuit upgraded, switching to Equity, Matthew Butterick’s excellent type family. Here’s a before and after tweet noting the change. The results are typographically sublime (including improved margins).

The gold standard is the U.S. Supreme Court, which uses Century Schoolbook. Yes, I just praised the Fifth Circuit’s change from Century Schoolbook to Equity as an upgrade, but tradition and consistency have their place. The Supreme Court’s typographic style has been stunningly consistent for — no pun intended — well over a century. (If only that were true of their recent decisions. Rimshot.) Here is last month’s Louisiana v. Callais decision — the gerrymandering/redistricting case. Here is 1954’s Brown v. Board of Education. I’d give the nod to the older one, which made better use of proper small caps, but the overall consistency is obvious.

Here is the 2026 edition of the Rules of the Supreme Court. Not only does the Court use Century Schoolbook for its own decisions, it requires submissions to the Court to use the same (p. 44):

The text of every booklet-format document, including any appendix thereto, shall be typeset in a Century family (e. g., Century Expanded, New Century Schoolbook, or Century Schoolbook) 12-point type with 2-point or more leading between lines. Quotations in excess of 50 words shall be indented. The typeface of footnotes shall be 10-point type with 2-point or more leading between lines. The text of the document must appear on both sides of the page.

Every booklet-format document shall be produced on paper that is opaque, unglazed, and not less than 60 pounds in weight, and shall have margins of at least three-fourths of an inch on all sides. The text field, including footnotes, may not exceed 4⅛ by 7⅛ inches.

Why the extra one-eighths of an inch instead of just 4 × 7? I don’t know. But 4⅛ × 7⅛ is exactly the size of the text field in the court’s own decisions.

Now compare the current 2026 rulebook to this edition printed in 1910 (with rules adopted in 1884). The consistency is striking — but, once again, the older version makes better use of small caps and just has a bit more vim and vigor to it. Just look at page 44, for example. It’s perfect. The current Court’s document formatters should aspire only to more closely ape the confidence and sturdiness of this older one. A century from now, U.S. Supreme Court decisions should look as similar to today’s as today’s do to those from a century ago.

The various circuit courts using lesser typefaces, looser margins, and lazier formatting should follow the Fifth’s lead and get their shit together. Tuck your shirt in, comb your hair, straighten your tie, and pop a mint in your mouth. If you’re a United States federal court, your typographic style should reflect that.

Back in 2020, Butterick took a well-deserved victory lap when the Fifth Circuit adopted Equity.¹ He quoted Fifth Circuit Judge Don Willett, a typography fan who spearheaded the restyling project, on its rationale. Willett wrote:

[Why] did the circuit devote finite judicial energy to swapping typefaces and widening margins? Simple answer: Our job is not just to present clear opinions, but to present our opinions clearly. Getting the law right is, of course, our tip-top priority. Nothing matters more. ... But good enough is never good enough. Our work is consequential, impacting the lives and livelihoods of real people walloped by real problems in the real world. The stakes are high, and we must present our best opinion, not merely a passable one. And that presentation begins before the first word is ever read.

Journalist and author Steven Rosenbaum has more reasons than most to distrust AI.

His new book, The Future of Truth: How AI Reshapes Reality, is all about "how Truth is being bent, blurred, and synthesized" thanks to the "pressure of fast-moving, profit-driven AI." Yet a New York Times investigation this week found what Rosenbaum now acknowledges are "a handful of improperly attributed or synthetic quotes" linked to his use of AI tools while researching the book.

These quotes include one that tech reporter Kara Swisher told the Times she "never said" and another that Northeastern University professor Lisa Feldman Barrett said "don’t appear in [my] book, and they are also wrong." Rosenbaum is now working with editors on what he says is a full "citation audit" that will correct future editions.

Read full article

Comments

Learn how to respond when your CFO asks, "why are our devs still writing code?"

In my last post, I argued why you should still type code by hand. If you aren't writing code, you're programming in English (or German, Chinese, etc.) and asking an LLM to translate. Businesses love that idea because a lot more people speak English than write JavaScript and will work at overseas call center rates. Read on to learn why that won't work.

Thoughtworks is a software consultancy that developers and business execs look to for practical guidance in software engineering. In February, some of them got together¹ to discuss coding with LLMs. There, someone asked this question²:

What would have to be true for us to ‘check English into the repository’ instead of code?

I felt disappointed to hear expert software practitioners considering this question, because it will be about thirty seconds before it is reframed as a LinkedIn post confidently proclaiming that code is dead. After that, it will be two minutes before your CFO posts it in a chat with your manager.

I'll grant that code is a cost center. Each line is a recurring operational expense that climbs for the life of the product. Just look at the pink line from my recent post on software failures. You can mentally substitute "failures" with "cost":

Your CFO would gladly shed this expense, and he hopes that LLMs are that golden ticket. You can stop this train wreck if you know where the railroad switch is. The language your leaders hear can switch the trajectory of the business before it careens off the cliff of LLM dependence and layoffs.

Below, you'll learn precisely what would have to be true for businesses to program purely in English, do away with those cumbersome programming languages, and fire those expensive programmers.

How the software sausage is made

In order to understand what it would take to replace code, we need to know the role that code plays when creating software. Let's start with a simplified model of software development:

[specification] ---> [code] ---> [executable] ---> [program] ---> [test]

The model above intentionally ignores details like iteration and feedback. Let's look at the transition between each step.

From spec to code

In general, software developers take a specification and turn it into code.

A spec describes, in language that a broad audience can understand, what the software must do or not do. It consists of one or more requirements. Here's an example requirement:

The app SHALL page the on-call engineer if the server is down or the response is slow and it's during business hours.

Creating a good spec can be difficult. Let's remember Brooks' wisdom that producing the spec is the hard part, not implementation:

The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a programⁱ is in fact the debugging of the specification

-- Fred Brooks, No Silver Bullet, 1986

I already demonstrated Brooks' point. The paging requirement above is ambiguous. Did you notice? Look again.

To turn the paging rules above into code, a dev has to disambiguate between two possible meanings:

• Never page outside work hours: (server_down OR response_slow) AND business_hours
• Always page on outages, and only page on slowness during work hours: server_down OR (response_slow AND business_hours)

Unlike English, code is an unambiguous language. To express the paging rules above in C, Python, or JavaScript, a programmer has to choose one of the precise interpretations. If they leave off the parentheses, the language's operator precedence rules determine which of OR and AND gets evaluated first.

Choosing the correct interpretation requires a conversation with someone who knows what the software is supposed to do.

Spec is legible; code is precise

You might think, "What idiot wrote that vague requirement?", but before you judge, remember that specs are imprecise on purpose. Precision and legibility are opposing attributes. "Ensure the email address is valid" is legible, but ^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$ is precise. Both levels are necessary; one communicates intent, the other actually does the work. Similarly, "Round to two decimals" is legible, but the IEEE 754 rules for rounding occupy an 84-page document³.

It is of course possible to write a specification in English that contains no ambiguity. The cost of producing it would be greater than the cost to produce the equivalent code. That's because there's no program checking syntax and enforcing a type system. For example, I've read plenty of spec documents that used terms they did not define. Without some kind of automated correctness check, a precise English specification is likely to accumulate omissions and inconsistencies over time. This is especially likely for multiple documents made by multiple contributors.

Let's pretend that some organization succeeded in creating a software specification that is precise enough to replace code. The language of that document would be hard to read for the same reasons that code is hard to read. As others have said, "a sufficiently detailed spec is just code."⁴

From code to executable

Once we have some code, a program called a compiler reads the code and outputs an executableⁱⁱ. An executable is a file that contains the data and sequence of instructions that work on a specific processor.

The transformation from code to executable is deterministic: the compiler will always output the same executable, given the same code. We'll come back to that in a moment.

From executable to program

Once we have an executable, we can load it into memory and run it. We call that a program. Once we can run a program, we can test it in two ways:

Verification. We ask "Did we build the thing right?" We check if the code implements the spec. It can be done with manual interaction with the program, but it's best to use automated tests because humans are not fast or consistent.

Validation. We ask "Did we build the right thing?" We hand the executable to the user and ask for feedback. This pits the user's expectations against both the spec and code. Any of the three can change as a result.

How to replace code with English

Let's assume for the sake of argument that LLMs actually can parse English specifications, even ambiguous ones, and output the equivalent code that devs would. In that universe, we would delete the code and only store the spec in source control:

[specification] ---------------> [executable] ---> [program] --> [test]

On each build, the LLM would generate the code, build the executable, and run the tests. Then it would discard the code it had generated.

We do not live in that universe.

LLMs can't always resolve ambiguity. If the spec has issues, they'll need clarification, just like devs do. You'll be lucky if they ask for it. Do you want your deploy to prod to stop while an LLM waits for an email reply?

LLMs are not generally deterministic. I promised we'd circle back to this topic. If you give an LLM the same prompt twice, you'll get different output. This presents a problem for verification and validation. Since the artifact changes with each build even if the spec did not, the tests must validate a range of valid specs rather than just one. It's like hitting a bullseye with a bow and arrow. The more the tests constrain the set of executables that will pass, the harder the LLM has to work.

There's no opportunity to inspect the code the LLM generated and no value of doing so, since on each run it is different. This places further load on the test suite for proving correctness.

In light of these facts, here's what would have to be true to use English in the place of programming languages:

• The specification would have to be unambiguous. It would be pedantic English that makes C++ look pleasant.

• The tests would need to be comprehensive, automated, and epistemologically sound.

  • Tests serve as a forcing function that constrain the executable to one that satisfies the spec.

  • The tests have to actually verify the executable meets the spec.

    Do you ask the LLM to write a test, then review the test, run it, and see it fail? Then stage the code changes? Then ask the LLM to pass the test? Then verify that the LLM did not change the test while passing it? Review the additional code change? Commit and repeat? If so, this sounds epistemologically sound. ⁵

  • The tests have to be written in code. If you write them in English and ask the LLM to generate test code, the bullseye moves on each build. Moreover, what verifies the generated tests?

• The LLM would need to be deterministic, or your budget must be ready to absorb massive token spend. That's because on each CI run, the LLM would iterate in a test-edit loop until the tests pass.

The industry already tried to code in English

In the 1960s, the industry adopted two languages that look like English.

The hope behind COBOL was that business analysts would be able to implement their ideas without programmers.

ADD OVERTIME-HOURS TO TOTAL-HOURS GIVING WEEKLY-HOURS ROUNDED.

The above code can be expressed in JavaScript as const weeklyHours = Math.round(overtimeHours + totalHours);. The cosplay didn't protect workers from having to think hard and understand the problem they were solving. Today, the small priesthood of surviving COBOL programmers are remunerated with airdrops of cash to keep the core of the world's banking infrastructure running.

SQL had similar goals. The query below looks friendly enough, but debugging it requires knowledge of set theory, query planners, indexes, and idiosyncrasies of the SQL flavor. These days, DBAs easily earn six figures.

SELECT FROM orders WHERE status = 'cancelled' AND created_at < '2025-01-01';

Edsger Dijkstra was probably to computer science what Einstein was to physics. The emergence of English-like languages caused him to pen a rather forceful essay⁶ which can be summed up with this sentence:

some still seem to equate "the ease of programming" with the ease of making undetected mistakes.

What to tell your CFO

Here's what you can tell your CFO when he asks why we still have devs on payroll:

Code is already the cheapest path to working, correct software. LLMs do not change the calculus because figuring out what to make is the expensive part, not coding it up. Skipping code makes the specification of what to make even more expensive and throws away the tools that keep precision affordable. Programming in English would be more expensive than just using a programming language.

Bookmark this page or save this paragraph. You'll need it soon enough.

Further reading

If this post clicked with you, I drum a similar beat about business, coding, and LLMs:

• AI: Accelerated Incompetence: "In software engineering, over-reliance on LLMs accelerates incompetence."
• LLMs are not Bicycles for the Mind: "LLMs are more like E-bikes. More assist makes you go faster, but provides less exercise"
• Who wins in an Arms Race?: "In a competitive landscape, LLMs, like supershoes, do not result in your benefit"
• Why you should still type code in 2026: "When you type code by hand, you get the best of LLMs without losing your coding skills"

Footnotes

1. Historically, the industry used the term program as shorthand for program text, what today we call source code.
2. I'm ignoring interpreted languages like JavaScript and Python. They aren't compiled. They produce the executable the moment you want to run it. I'm also ignoring languages that compile to intermediate representations, like Java or C#. These details don't matter for this discussion.

References

1. The Future of Software Development
2. Finding Comfort in the Uncertainty
3. IEEE Standard for Floating-Point Arithmetic
4. A sufficiently detailed spec is code
5. AI-generated tests as ceremony
6. On the foolishness of "natural language programming".