TheDaily Front

Risky Bulletin: Slovakia finds Russian backdoor in traffic speed cameras

Slovakia's national security service NBU has issued a security alert against the use of NERO R-ONE high-speed traffic cameras.

The agency says the cameras contain a backdoor mechanism that grants shell and network access to the devices via an SMS message received from a list of hardcoded Russian phone numbers.

The NBU started an investigation into the devices after the country's opposition accused the government of buying the cameras from Russia and after multiple reports in Slovak media that linked the purchase to a Cyprus shell company with fake certifications.

According to the NBU, the cameras are a rebranded version of a Russian traffic camera model named CORDON PRO.M, produced by St. Petersburg-based Russian firm Semicon.

via NBU

via NBU

The cameras were bought as part of a €30 million EU-funded project to rebuild the country's national traffic monitoring system.

The Interior Ministry has allegedly bought and preparing to install 279 cameras on selected roads across Slovakia.

The Ministry initially denied that the cameras were of Russian origin and said there's no danger of data theft since the devices were going to be on a closed loop Ministry network.

According to an NBU technical report, besides the backdoor system, the cameras also contain several security flaws. They have a crucial SecureBoot security feature that's turned off so the firmware origin is never enforced, the web management portal contains multiple vulnerabilities, and the cameras expose live streams to anyone without a password and who knows their broadcasting IP.

Interior Ministry officials paused the camera deployment after the NBU report and said it would order an additional assessment from an independent auditor to confirm the findings.

Some similar devices are also allegedly installed in Croatia and maybe some other countries in Eastern Europe.

Source

Nobody should be buying security cameras from Russia, or China for that matter https://t.co/ZiuuZ3ODjQ

— ChrisO_wiki (@ChrisO_wiki) August 18, 2026

Breaches, hacks, and security incidents

Scammers target UK prime minister: A scammer targeted UK Prime Minister Andy Burnham by posing as White House chief of staff Susie Wiles. Burnham detected the scam himself and the UK embassy notified the White House. Multiple US senators, governors, and executives were also targeted by scammers posing as Wiles last year. The White House blamed the incident on a hacker obtaining a copy of her cellphone contacts. [Politico Europe]

Hackers target Ukraine's ARMA agency: A cyberattack has disrupted the activities of Ukraine's agency for managing seized Russian assets. The attack took place this week as the agency was preparing to assign a new manager for beverage company IDS Ukraine. Ukraine seized IDS from Alfa-Bank co-founder Mikhail Fridman shortly after Russia's invasion. The agency didn't attribute the attack. [RBC // ARMA]

Hack hits Berlin government: A cyberattack has disrupted two major departments in the Berlin city government. The attack took down emails, remote gateways, and internet connections across the transport and urban development departments. IT staff have disconnected the two agencies from the city network to prevent the incident from spreading. [Tagesspiegel // RBB24 // Yahoo Finance!]

Breach at genetics testing company: Genetics-testing company Baylor Genetics is notifying users of a security breach that exposed their personal information. The breach took place in June and both patient and employee data was compromised. The company didn't disclose the number of affected individuals. [Baylor Genetics // CybersecurityDive]

UT San Antonio breach: The University of Texas at San Antonio has taken its IT systems offline after a security breach over the weekend. Classes for the new school year are expected to start on Wednesday as scheduled. The university has extended tuition payment deadlines and plans to reset all user account passwords once systems are online. [UT San Antonio // The Record]

Ransomware disables hospital doors, HAVC: A ransomware attack has disabled access doors, heating, ventilation, and air conditioning at Winnipeg's largest hospital. The Winnipeg Health Sciences Centre increased onsite security while the access card system is still down. The hospital says patient care and clinical operations are not impacted. [CBC // The Winnipeg Free Press] [h/t Alex Rudolph]

BlueSky and GitHub hit by Iranian DDoS attacks: An Iranian hacktivist group took down BlueSky and GitHub with DDoS attacks on Sunday and Monday, respectively. The attacks caused prolonged outages at both companies. A group known as the 313 Team took credit for the attacks. The hackers were also behind another wave of DDoS attack in April. [Telegram // Telegram]

We apologize for yesterday’s service problems. Bluesky experienced a DDoS attack—a flood of junk traffic meant to knock servers offline—over a period of 24 hours. We have upgraded our defenses in response, and we continue to monitor the situation. Follow @status.bsky.app for any updates.

— Bluesky (@bsky.app) August 18, 2026 at 12:27 AM

SafePal breach: Hackers have stolen the personal information of 40,000 customers of hardware crypto-wallet provider SafePal. The incident impacted all customers who placed orders of SafePal wallets between March 2, 2025, and April 11, 2026. SafePal says no seed phrases or private keys are impacted. The stolen data is still dangerous because it could enable wrench attacks on wallet holders. [SafePal // SecurityWeek]

Bits of Gold breach: Hackers have stolen the data of 250,000 customers of Bits of Gold, Israel's largest cryptocurrency exchange. The company notified customers of the hack over the weekend. It said the data was stolen from an external analytics service provider. It didn't say what type of data was stolen. [CTech]

TheHatman dumps employee data for a dozen companies: A threat actor is selling the employee data of almost a dozen Fortune 500 companies. The hacker, who goes by TheHatman, claims the data was stolen by using stolen credentials to access each victim's Azure environments. The hacker claims they breached McDonalds, Vodafone, Gap, and the Intercontinental and Wyndham hotel chains. [HudsonRock]

AI, general tech, and privacy

Windows 11 drops WMIC: The current Windows 11 installation packages and Insider Builds do not ship with the Windows Management Instrumentation Command-line (WMIC) feature anymore. Microsoft deprecated the toolkit a few years ago after it saw massive abuse. [Microsoft // WindowsLatest]

Firefox 154: Mozilla has released Firefox 154. New features and security fixes are included. The biggest feature in this release is support for GeForce NOW, NVIDIA's cloud gaming platform. [Firefox]

Firefox for iOS gets an ad blocker: Mozilla has added an ad blocker to Firefox on iOS. It is turned off by default. [Mozilla]

Government, politics, and policy

Russian things: A Russian court has forced two Telegram channel owners to remove posts blaming the country's internet watchdog for causing an outage of the country's banking system as part of an attempt to block VPN protocols. This is funny to me because they didn't fine Natalya Kaspersky, one of the Kaspersky co-founders, for basically saying the same thing in an official manner and to more mainstream Russian news outlets. Alas, Russia, a two-tiered society! [Caution News on Telegram]

Arrests, cybercrime, and threat intel

French cops used public exploit to hack EncroChat: French law enforcement used a public exploit hosted on GitHub to hack encrypted phone network EncroChat in 2020. The exploit was for the Bad Binder Android vulnerability and had been shared online a few months before. EncroChat discovered the hacks after French cops deployed a second exploit that failed. [ComputerWeekly // Bad Binder exploit on GitHub // Bad Binder write-up]

Source

SMS blaster arrested in Malaysia: Malaysian authorities have arrested a 65-year-old suspect for driving around with an SMS blaster in his car. The suspect was detained driving around the border crossing between Johor Bahru and Singapore. He is the second suspect arrested this month in Johor Bahru for SMS blasting. [CommsRisk]

LockerGoga dev on trial in Switzerland: Swiss prosecutors are seeking a 12-year prison sentence for a Ukrainian man linked to ransomware attacks on local companies. Officials claim the suspect was a coder for the LockerGoga, MegaCortex and Nefilim ransomware groups. The suspect is pleading not guilty. He claims he was working as a consultant for a cybersecurity firm when he was detained and the ransomware source code found on his devices. [Watson // The Record]

Ransomware affiliate poses as data recovery firm: A ransomware affiliate is posing as a data recovery firm named Ransom Busters LTD. According to GuidePoint Security, the group has reached out to multiple companies and offered to delete their data from ransomware servers for a fee between $20,000 and $60,000. The group has reached out to victims even before breaches were made public. GuidePoint believes the group has signed up as an affiliate on different Ransomware-as-a-Service platforms to see hacked companies and reach out in advance. [GuidePoint Security]

Operation CameraSwarm: A threat actor has hacked more than 14,500 Dahua security cameras across Ukraine and Russia. Researchers at Hunt Intelligence discovered the botnet after the hacker left an open directory on their server infrastructure. According to files recovered from the server, the hacker exploited old vulnerabilities but also a secret hardcoded account in some of the devices. [Hunt Intelligence]

StopAndProtect profile: Security firm Check Point has published a profile on StopAndProtect, a new e-crime operation using thousands of hacked WordPress sites to redirect users to malware downloads and then store stolen creds. [Check Point]

FUXA scanning: Threat actors are scanning for FUXA SCADA devices in an attempt to exploit CVE-2026-25895, an unauthenticated path traversal that can let hackers rewrite local files. [Caitlin Condon on LinkedIn]

StubMaker RubyGems campaign: The OSM team has spotted 16 malicious RubyGems packages typosquatting more popular packages that spread a Windows infostealer to whoever installs them. [OpenSourceMalware]

Malware technical reports

DragonDoll Android spyware: Russian security firm Positive Technologies has discovered a new Android spyware strain. Named DragonDoll, the spyware is spread using fake Chrome update packages and focuses on stealing data from instant messengers. [Positive Technologies // Archived]

GoldDigger Android trojan: IBM's Trusteer team has published a technical analysis of GoldDigger, an Android banking trojan active since 2023. [IBM]

C2Looper backdoor: In July 2026, researchers identified C2Looper, a new malware family likely used in ransomware attacks to establish a foothold for lateral movement. [Zscaler]

TWINLOOT: Ontinue researchers have discovered TWINLOOT, a Python-coded malware framework that hosts its entire command-and-control infrastructure inside trusted Microsoft services such as Azure, M365, and SharePoint. [Ontinue]

MacSync Stealer: Microsoft has released a technical report on MacSync Stealer, a recent infostealer targeting the macOS ecosystem. [Microsoft]

WordlistLoader: Gen Threat Labs has identified WordlistLoader, a new loader used to deliver Amatera Stealer via ClearFake campaigns. [Gen Digital]

Shadow HVNC and Shadow Loader: Security researchers have reverse-engineered Shadow HVNC and Shadow Loader, two malware families advertised online by a developer known as RemoteX. [Malbear Labs]

ValleyRAT: Despite some arrests this year, the SilverFox group is still active and spreading its ValleyRAT malware. [Forcepoint]

AZALEA RAT: And speaking of RATs, Point Wild looks at the distribution chains of the AZALEA RAT, a new RAT advertised online as AzaleaControl. [Point Wild]

Medusa ransomware: CISA has updated its advisory on the Medusa ransomware with new TTPs. The agency says the group has continued to be active and made hundreds of new victims. [CISA]

Mirage2FA: ANY.RUN's security team looks at a new 2FA-intercepting phishing service named Mirage2FA. The service seems to be geared towards M365 campaigns primarily. [ANY.RUN]

APTs, cyber-espionage, and info-ops

France investigates Russian disinfo ops: French authorities have launched an investigation into suspected Russian disinformation campaigns targeting the country's pro-EU politicians. The campaigns targeted possible presidential candidates Gabriel Attal and Edouard Philippe as soon as they showed interest in next year's election. Open-source reporting has linked the campaigns to a Russian disinformation group known as Matryoshka and Storm-1516. [FranceInfo]

Operation QUICSILVER: A China threat actor has been targeting Myanmar diplomats via an VHD-delivered Go backdoor named QUICAgent. [Seqrite]

Goffee replaces image files: The Goffee cyber-espionage group has maintained a foothold inside hacked organizations by altering installation images for corporate apps. In a campaign targeting Russian companies, the group has modified 7-Zip and Git installers. [F6]

Core Werewolf's CoreRAT: A highly sophisticated APT group named Core Werewolf has continued its operations targeting Russian orgs with a new remote access trojan named CoreRAT. [BI.ZONE]

Russia and US hold hands in Alberta info-ops: The US and Russia appear to have joined hands in promoting the Alberta separatist movement in Canada. [The Globe and Mail]

"The first data from a study that began last month indicate Russian content farms have been pushing pro-separatist content into online communities and using Canadians to “launder” those messages by sharing such material on their social media feeds, the researchers said. The U.S. activity, on the other hand, is more overt, with prominent American influencers, podcasts and websites openly promoting Alberta separation, said Brian McQuinn, co-director of the Centre for Artificial Intelligence, Data, and Conflict at the University of Regina."

CopyCop (Storm-1516) in Armenia: Russian disinfo group CopyCop ran a disinformation campaign trying to sabotage the construction of a shared US-Armenian AI data center in Hrazdan. [Recorded Future]

PurpleDelta: Recorded Future has identified 22 new personas operated by PurpleDelta, the name the company assigns to North Korea's remote IT worker scheme. Also this week, Bridewell published a guide on how to defend against these groups. [Recorded Future // Bridewell]

Iranian phishing ops target Israeli journalists: Iranian state hackers have intensified spear-phishing attacks targeting Israeli journalists. The country's intelligence and cybersecurity agencies have sent out a security alert about the attacks last week. The agencies say hackers are seeking to obtain private information from journalists reporting on political and national security. [Ynet]

US charges more Mabna hackers: The US has unsealed a superseding indictment against 17 Iranian hackers. The suspects are employees of the Mabna Institute, a cyber contractor for Iran's Islamic Revolutionary Guard Corps. The Justice Department claims Mabna hackers breached universities across the world to steal research and transfer to Iranian counterparts. The superseding charges replace a 2018 indictment that expands the number of suspects from nine to 17. The State Department has also offered a $10 million reward for information that may lead to the arrest of any of the suspects. The Mabna Institute hacking campaigns are tracked by security firms under the codename of Cobalt Dickens. [DOJ 2026 // DOJ 2018 // Rewards for Justice // Sophos]

Vulnerabilities, security research, and bug bounty

Security updates: Apple, Dell, Edge, Firefox, GitLab, Oracle, Tenable, Tor Browser.

AI agent introduces bug in Snowflake's production: Security firm Wiz has spotted an AI coding agent autofixing a bug but introducing a vulnerability in cloud provider Snowflake's production systems. [Wiz]

Microsoft delays Exchange updates due to influx of AI bugs: Microsoft has delayed a major update for Exchange Subscription Edition servers due to an influx of AI-discovered vulnerabilities. The update was supposed to go live at the end of June. Microsoft says it did not want to release its biannual feature update only to release multiple batches of security fixes right after. The company plans to wait to fix all security bugs before releasing the Exchange SE H1 Cumulative Update. Microsoft says employees discovered the security flaws as part of an internal push to use AI tools for bug discovery. [Microsoft]

KEV update: CISA has updated its KEV database with four vulnerabilities that are currently exploited in the wild. All are 2026 bugs, such as a recent Apple macOS ScreenShare bug, a Microsoft IKE one, a SharePoint one, and a VMware vCenter path traversal.

Infosec industry

Acquisition news: Tech giant Fortinet has acquired AI security startup Virtue AI, which specializes in AI runtime protection, automated AI validation, and security for autonomous AI systems. [Fortinet]

Threat/trend reports: Beazley Security, Black Kite, Bridewell, Cyberproof, Ecosyste.ms, JPMorgan, MinterEllison, and Onyxia have recently published reports and summaries covering various emerging threats and industry trends.

1. Complex systems are intrinsically hazardous systems.

   All of the interesting systems (e.g. transportation, healthcare, power generation) are inherently and unavoidably hazardous by the own nature. The frequency of hazard exposure can sometimes be changed but the processes involved in the system are themselves intrinsically and irreducibly hazardous. It is the presence of these hazards that drives the creation of defenses against hazard that characterize these systems.

2. Complex systems are heavily and successfully defended against failure

   The high consequences of failure lead over time to the construction of multiple layers of defense against failure. These defenses include obvious technical components (e.g. backup systems, ‘safety’ features of equipment) and human components (e.g. training, knowledge) but also a variety of organizational, institutional, and regulatory defenses (e.g. policies and procedures, certification, work rules, team training). The effect of these measures is to provide a series of shields that normally divert operations away from accidents.

3. Catastrophe requires multiple failures – single point failures are not enough.

   The array of defenses works. System operations are generally successful. Overt catastrophic failure occurs when small, apparently innocuous failures join to create opportunity for a systemic accident. Each of these small failures is necessary to cause catastrophe but only the combination is sufficient to permit failure. Put another way, there are many more failure opportunities than overt system accidents. Most initial failure trajectories are blocked by designed system safety components. Trajectories that reach the operational level are mostly blocked, usually by practitioners.

4. Complex systems contain changing mixtures of failures latent within them.

   The complexity of these systems makes it impossible for them to run without multiple flaws being present. Because these are individually insufficient to cause failure they are regarded as minor factors during operations. Eradication of all latent failures is limited primarily by economic cost but also because it is difficult before the fact to see how such failures might contribute to an accident. The failures change constantly because of changing technology, work organization, and efforts to eradicate failures.

5. Complex systems run in degraded mode.

   A corollary to the preceding point is that complex systems run as broken systems. The system continues to function because it contains so many redundancies and because people can make it function, despite the presence of many flaws. After accident reviews nearly always note that the system has a history of prior ‘proto-accidents’ that nearly generated catastrophe. Arguments that these degraded conditions should have been recognized before the overt accident are usually predicated on naïve notions of system performance. System operations are dynamic, with components (organizational, human, technical) failing and being replaced continuously.

6. Catastrophe is always just around the corner.

   Complex systems possess potential for catastrophic failure. Human practitioners are nearly always in close physical and temporal proximity to these potential failures – disaster can occur at any time and in nearly any place. The potential for catastrophic outcome is a hallmark of complex systems. It is impossible to eliminate the potential for such catastrophic failure; the potential for such failure is always present by the system’s own nature.

7. Post-accident attribution to a ‘root cause’ is fundamentally wrong.

   Because overt failure requires multiple faults, there is no isolated ‘cause’ of an accident. There are multiple contributors to accidents. Each of these is necessarily insufficient in itself to create an accident. Only jointly are these causes sufficient to create an accident. Indeed, it is the linking of these causes together that creates the circumstances required for the accident. Thus, no isolation of the ‘root cause’ of an accident is possible. The evaluations based on such reasoning as ‘root cause’ do not reflect a technical understanding of the nature of failure but rather the social, cultural need to blame specific, localized forces or events for outcomes. 1

   1 Anthropological field research provides the clearest demonstration of the social construction of the notion of ‘cause’ (cf. Goldman L (1993), The Culture of Coincidence: accident and absolute liability in Huli, New York: Clarendon Press; and also Tasca L (1990), The Social Construction of Human Error, Unpublished doctoral dissertation, Department of Sociology, State University of New York at Stonybrook)

8. Hindsight biases post-accident assessments of human performance.

   Knowledge of the outcome makes it seem that events leading to the outcome should have appeared more salient to practitioners at the time than was actually the case. This means that ex post facto accident analysis of human performance is inaccurate. The outcome knowledge poisons the ability of after-accident observers to recreate the view of practitioners before the accident of those same factors. It seems that practitioners “should have known” that the factors would “inevitably” lead to an accident. 2 Hindsight bias remains the primary obstacle to accident investigation, especially when expert human performance is involved.

   2 This is not a feature of medical judgements or technical ones, but rather of all human cognition about past events and their causes.

9. Human operators have dual roles: as producers & as defenders against failure.

   The system practitioners operate the system in order to produce its desired product and also work to forestall accidents. This dynamic quality of system operation, the balancing of demands for production against the possibility of incipient failure is unavoidable. Outsiders rarely acknowledge the duality of this role. In non-accident filled times, the production role is emphasized. After accidents, the defense against failure role is emphasized. At either time, the outsider’s view misapprehends the operator’s constant, simultaneous engagement with both roles.

10. All practitioner actions are gambles.

    After accidents, the overt failure often appears to have been inevitable and the practitioner’s actions as blunders or deliberate willful disregard of certain impending failure. But all practitioner actions are actually gambles, that is, acts that take place in the face of uncertain outcomes. The degree of uncertainty may change from moment to moment. That practitioner actions are gambles appears clear after accidents; in general, post hoc analysis regards these gambles as poor ones. But the converse: that successful outcomes are also the result of gambles; is not widely appreciated.

11. Actions at the sharp end resolve all ambiguity.

    Organizations are ambiguous, often intentionally, about the relationship between production targets, efficient use of resources, economy and costs of operations, and acceptable risks of low and high consequence accidents. All ambiguity is resolved by actions of practitioners at the sharp end of the system. After an accident, practitioner actions may be regarded as ‘errors’ or ‘violations’ but these evaluations are heavily biased by hindsight and ignore the other driving forces, especially production pressure.

12. Human practitioners are the adaptable element of complex systems.

    Practitioners and first line management actively adapt the system to maximize production and minimize accidents. These adaptations often occur on a moment by moment basis. Some of these adaptations include: (1) Restructuring the system in order to reduce exposure of vulnerable parts to failure. (2) Concentrating critical resources in areas of expected high demand. (3) Providing pathways for retreat or recovery from expected and unexpected faults. (4) Establishing means for early detection of changed system performance in order to allow graceful cutbacks in production or other means of increasing resiliency.

13. Human expertise in complex systems is constantly changing

    Complex systems require substantial human expertise in their operation and management. This expertise changes in character as technology changes but it also changes because of the need to replace experts who leave. In every case, training and refinement of skill and expertise is one part of the function of the system itself. At any moment, therefore, a given complex system will contain practitioners and trainees with varying degrees of expertise. Critical issues related to expertise arise from (1) the need to use scarce expertise as a resource for the most difficult or demanding production needs and (2) the need to develop expertise for future use.

14. Change introduces new forms of failure.

    The low rate of overt accidents in reliable systems may encourage changes, especially the use of new technology, to decrease the number of low consequence but high frequency failures. These changes maybe actually create opportunities for new, low frequency but high consequence failures. When new technologies are used to eliminate well understood system failures or to gain high precision performance they often introduce new pathways to large scale, catastrophic failures. Not uncommonly, these new, rare catastrophes have even greater impact than those eliminated by the new technology. These new forms of failure are difficult to see before the fact; attention is paid mostly to the putative beneficial characteristics of the changes. Because these new, high consequence accidents occur at a low rate, multiple system changes may occur before an accident, making it hard to see the contribution of technology to the failure.

15. Views of ‘cause’ limit the effectiveness of defenses against future events.

    Post-accident remedies for “human error” are usually predicated on obstructing activities that can “cause” accidents. These end-of-the-chain measures do little to reduce the likelihood of further accidents. In fact that likelihood of an identical accident is already extraordinarily low because the pattern of latent failures changes constantly. Instead of increasing safety, post-accident remedies usually increase the coupling and complexity of the system. This increases the potential number of latent failures and also makes the detection and blocking of accident trajectories more difficult.

16. Safety is a characteristic of systems and not of their components

    Safety is an emergent property of systems; it does not reside in a person, device or department of an organization or system. Safety cannot be purchased or manufactured; it is not a feature that is separate from the other components of the system. This means that safety cannot be manipulated like a feedstock or raw material. The state of safety in any system is always dynamic; continuous systemic change insures that hazard and its management are constantly changing.

17. People continuously create safety.

    Failure free operations are the result of activities of people who work to keep the system within the boundaries of tolerable performance. These activities are, for the most part, part of normal operations and superficially straightforward. But because system operations are never trouble free, human practitioner adaptations to changing conditions actually create safety from moment to moment. These adaptations often amount to just the selection of a well-rehearsed routine from a store of available responses; sometimes, however, the adaptations are novel combinations or de novo creations of new approaches.

18. Failure free operations require experience with failure.

    Recognizing hazard and successfully manipulating system operations to remain inside the tolerable performance boundaries requires intimate contact with failure. More robust system performance is likely to arise in systems where operators can discern the “edge of the envelope”. This is where system performance begins to deteriorate, becomes difficult to predict, or cannot be readily recovered. In intrinsically hazardous systems, operators are expected to encounter and appreciate hazards in ways that lead to overall performance that is desirable. Improved safety depends on providing operators with calibrated views of the hazards. It also depends on providing calibration about how their actions move system performance towards or away from the edge of the envelope.

This piece was also cross-posted on the Civics of Technology blog. This piece also has a followup post that you can find at Three Questions on Questions: On Asking, Knowing and Noticing

Two pieces crossed my feed recently, both about Sal Khan and the AI tutoring revolution that wasn’t. The first was Matt Barnum’s reported piece in Chalkbeat, where Khan himself acknowledged that Khanmigo, the AI chatbot tutor he launched three years ago with world-changing ambitions, was “a non-event” for most students. “They just didn’t use it much,” Khan said. His own Chief Learning Officer, Kristen DiCerbo, put it even more plainly: “So far I am not seeing the revolution in education.”

The second was Dan Meyer’s sharp obituary on LinkedIn, titled “RIP Khanmigo & Edtech Industry Dreams of AI Tutors.” Meyer traced the whole arc: the TED talk predictions, the philanthropic subsidies, the increasingly aggressive way Khanmigo inserted itself into the student experience (because students wouldn’t seek it out voluntarily), and the steadily shrinking user projections. His conclusion was blunt: if Khanmigo died with every advantage in the world (early OpenAI access, Microsoft backing, government subsidies, Sal Khan’s Rolodex), what hope should the rest of the edtech industry place in chatbot tutors?

These are important pieces, and I’d recommend reading both. But reading them, I found myself thinking about a deeper question. Not whether the revolution failed (it clearly did) but why it was never going to work in the first place.

To explain I have to go back a bit in time, back during my days at MSU, when I was out there giving talks about technology integration and the critical role played by the teacher in this entire process. And further about the significance of students actively constructing representations of their understanding.

So in these talks I used to show a clip from the Charlie Rose show (see below). It’s an interview where Khan describes how he prepares to teach a new topic. And it’s wonderful. Here’s Khan on learning about, say, Napoleon and the French Revolution:

“I approach it from what my brain would like to see… I like to see a scaffold, I like to see a map… what is the Holy Roman Empire, like where, what is that now?”

He reads Wikipedia first, “just to get the scaffold.” He draws timelines. He copies maps and pastes them onto his digital blackboard. And then he does something genuinely important: he pushes past the surface until he hits the questions that textbooks skip. Here’s Khan on the neuron:

“A biology book will tell you okay the signal goes across because there’s a myelin sheath and I’m like yeah but how does putting a little tissue around a neuron, how does it make the signal go faster? And no biology book will tell you that answer.”

So what does he do? He ponders. He thinks it through by analogy (fiber optics, signal amplification). And then he calls up friends who are biologists or communications engineers and asks: “Does this make sense?” Sometimes they confirm his intuition. And sometimes, beautifully, they say: “You know what, we don’t know.” Khan’s response to that is perfect: “Why didn’t the book tell me that?”

I used to play this clip and then ask the audience a simple question: Look at everything Sal Khan does to learn something. He reads widely. He scaffolds. He draws. He questions. He calls friends. He argues. He makes connections across fields. He builds intuitive understanding from the ground up. And then he builds something to capture all that he had learned to share with others.

Now… how does Sal Khan want my kid to learn?

Watch a video.

The room always got it immediately.

Because nobody in that room would accept that for themselves. We all know, intuitively, that watching someone else explain something is not the same as understanding it. We would never settle for that as learners. And yet, somehow, we accept it as a solution for other people’s children. This is a version of a phenomenon that I have written about earlier: The reductive seduction of other people’s problems.

But there’s a second layer that I think is even more important, and that neither the Chalkbeat piece nor Meyer’s critique quite names. Khan’s personal learning wasn’t just active. It had a purpose. He was learning in order to make something. The video was his construction, his artifact, the thing he was building. That’s what pulled him through the hard parts, through the myelin sheath question and the calls to friends and the hours of immersion. He had a destination.

Students watching the video have no such destination. They’re receiving the product of someone else’s learning process. And when Khanmigo came along, the revolution was… a chatbot to help you receive more efficiently. Still no purpose. Still no making. Still no reason to push through difficulty. No wonder DiCerbo reported seeing more “IDK IDK” than substantive engagement. No wonder teachers at early-adopter schools found that students “didn’t really care for the bot.” Why would they? There was nothing at stake for them.

This is where John Dewey, writing over a century ago, becomes useful. Dewey argued that learning is built on four natural impulses: the impulse to inquire, to construct, to express, and to communicate. He saw these not as skills to be taught but as drives already present in every learner, drives that education should work with rather than suppress.

Go back to the Charlie Rose clip and watch Khan through this lens. He is living all four. Inquire: the relentless “why” questions, the refusal to accept surface explanations, the “why didn’t the book tell me that?” Construct: the timelines, the maps, the blackboard drawings, the scaffolds he builds for himself. Express: the video itself, Khan giving form to what he’s understood. Communicate: calling up buddies, testing his ideas against other minds, discovering together what is and isn’t known. And then building a representation of his learning, with his own unique voice and style, and sharing it with the world. Inquiry, construction, communication and expression—all in one go! Intermingled so well that it is difficult to tell them apart.

All four impulses, firing beautifully.

And none of them available to the student on the other end.

Khan’s great error, I think, was not a failure of effort or sincerity. It was a failure of educational imagination. He experienced the full richness of learning and then designed a system that offered students only the residue. He gave them the destination without the journey. And because the journey is where motivation lives, where purpose lives, students quite reasonably declined the offer. First they declined the video (or rather, passively consumed it). Then they declined the chatbot. In both cases, the diagnosis was the same: nobody had given them a reason to care.

And this is what I think the edtech world keeps getting wrong. The assumption is that if you can deliver the right content, in the right way, at the right time, learning will follow. It won’t. Not without purpose. Not without the impulse to inquire, construct, express, and communicate. Not without, in Dewey’s sense, the learner actually doing something.

Teachers know this. It is, in fact, a large part of what teachers do: take something a student is not yet interested in and create the conditions that make them interested. Not through tricks or gamification but through the design of experiences that activate those Deweyan impulses. That is the work. And it is work that no video, and no chatbot, has figured out how to do.

I’ve written recently about how evolution’s answer to an unpredictable world was not “more data” but play, and about how children are optimized not for pattern-completion but for exploration. The connection to the Khan story is direct. Khan Academy, and then Khanmigo, are both autocomplete strategies: one autocompletes explanation, the other autocompletes tutoring. Neither makes room for the exploration, the construction, the messy purposeful making that is where learning actually happens.

Khan himself seems to have arrived at something close to this realization. “I think our biggest lever is really investing in the human systems,” he told Barnum. That’s a remarkable sentence from someone who has spent nearly two decades trying to improve education by routing around the humans. Whether his benefactors in the technology industry will be as excited to invest in human systems as they have been in software that tries to replace them… that remains to be seen.

Endnote: I don’t usually bring TPACK into my blog posts. I mean, how much weight can a Venn diagram carry? But this might be the cleanest case I’ve ever seen. Khan has technology knowledge in spades. He clearly has deep content knowledge (that Charlie Rose clip is proof enough). What he has never had is pedagogical knowledge: an understanding of how people learn, what motivates them, what makes the difference between someone who pushes through difficulty and someone who types “IDK.” The circle marked P in the Venn diagram. That is where the humans live. Content and Technology mean nothing without that.

“How do you find problems worth working on?” a senior engineer I mentor asked me recently. He’s trying to make the jump to staff engineer and realized that the role isn’t just about doing the work he’s assigned. He also needs to get involved in figuring out what his team and org should be building.

Someone else had suggested blocking out time in his calendar to think about the bigger picture. He’d tried that, but hadn’t found it productive, so he asked if I had any alternatives.

I told him I rarely find good problems by staring at a blank page and trying to “think strategically.” Instead, I act like a sponge. I listen to the stream of day-to-day noise, absorb the problems people are having and let them sit in the back of my mind. Over time, some fade away while connections begin to appear between others that initially seemed unrelated. Eventually, I start to see what’s really slowing people down and what my team or I can do about it.

I’ve worked with many engineers who’ve never really tried this. They wait for managers or leads to identify opportunities, then demonstrate their value by solving the hardest assigned problems. That can absolutely lead to promotion. But the projects that have made the biggest impression in my career were the ones where I found and solved an important problem my leaders did not yet realize existed.

One caveat: my experience comes mainly from working on infrastructure and developer tools at large companies, on teams where engineers have a lot of bottom-up autonomy to influence their roadmaps. In a more top-down environment, there may simply be less room to work this way.

Absorb problems, not requests

People love talking about the problems they are facing: in meetings, chat threads, presentations and email. They explain why their work is hard, complain about what slows them down and describe what they wish they could do.

When something overlaps with my area, I start pulling on the thread. I might ask, “If X existed, would it solve your problem?” or point them at an existing feature in a product I own and ask how much of their use case it covers.

Users often ask for a particular solution instead of explaining their root issue. Rather than taking the request at face value, I keep digging until I understand what they are trying to accomplish and why existing products do not work for them.

As a natural introvert, this sort of ambient listening works particularly well for me. I don’t need to fill my calendar with speculative meetings just to find ideas; there is already an enormous amount of useful information flowing around me during a normal week.

When a problem seems worth exploring, though, I become more active; I need to see how it affects the team’s day-to-day work. I’ll sit with them as they walk me through their workflows and the bugs they’re investigating. When I can, I’ll try working through some of those bugs myself. Seeing the problem firsthand makes it easier to separate what the team actually needs from the solution they asked for.

I also seek out people who see more of the organization than I do: those who own critical systems, work across several teams or have particularly deep insight into the work downstream of my team. I’ll arrange a 1:1 or coffee chat and ask about interesting problems they’ve come across. They may have already seen the same issue in several places and started connecting the dots, giving me a head start on patterns I might otherwise have taken much longer to notice.

Let problems accumulate

Several times, I’ve been burned by moving too fast. I became excited by a request from a vocal team, built the feature and watched them barely use it. Their priorities had changed, or the request had come from a one-off investigation that no longer mattered. How eager a team was in that moment wasn’t the same as how important the feature was relative to everything else my product needed to support. By hyperfocusing on their request, I lost sight of the bigger picture.

That taught me to let potential problems pile up. Listening the way I do leaves me with far more of them than I could possibly solve, and not all deserve action. Most don’t need to turn into projects the first time I hear about them; waiting can be a superpower.

Waiting means the same problem might pop up independently in different teams, making it a higher priority to solve. Or problems that look different on the surface might turn out to have the same shape, so I can address several use cases in one shot. Or, as I’ve learned painfully, the requesting team didn’t even care that much in the first place.

Instead, I make a mental note and revisit the problem if it comes up again. Other engineers I know write this sort of thing down more systematically. The mechanism is a personal choice: everyone has to figure out what works for them. What matters is keeping unresolved problems around long enough for more evidence to accumulate.

Find the common shape

Waiting helps me collect evidence, but that alone doesn’t tell me what to build. I still need to work out whether the problems I’ve retained are genuinely related and what, if anything, could address them together.

Perfetto, the performance debugging tool I work on, is a good example. It displays recordings of system activity on a timeline made up of rows called “tracks.” Over a couple of years, teams kept asking for small, specific additions to the UI. One wanted a command to keep their preferred tracks pinned to the top of the screen; the next team wanted the same, but for a completely different set of tracks. Others wanted Perfetto to open already zoomed in on a particular part of a recording, or to show a custom aggregation tuned to what they cared about. A few had stopped waiting for us and built elaborate workarounds with bookmarklets.1

By the time enough of these had piled up, my head was the usual tangle: the requests themselves, the constraints on each and a handful of half-formed solutions. I’ve learned not to force a solution by just sitting at a desk and thinking. Instead, my best untangling happens on long, aimless walks around London, where connections come more easily when I’m not trying to force them.

What I eventually realized was that none of these teams really wanted the specific feature they’d asked for. Each wanted to personalize Perfetto for their own workflow without imposing their choices on everyone else. The underlying need wasn’t any one feature but rather the ability to extend the UI. When a connection like that finally clicks, it’s one of the best feelings in the job: several awkward requests collapse into a single idea, and possibilities open up that none of them hinted at on their own.

That feeling, though, is exactly when I have to be careful, because a common shape is only a hypothesis and elegance is not evidence. When it happened with extending the UI it turned out to be real, but I’ve been fooled before.

In another recent case I was convinced that building a transparent caching system for querying Perfetto traces would solve issues with sharing large traces and repeated queries. It was only as I wrote the RFC and built a prototype that I realized the elegance was a lie: the two problems wanted genuinely different solutions. I reluctantly split the design in two, both halves of which have since shipped.2

Pressure-test before building

You’d think this would be the moment I start building, but it usually isn’t. How far I go depends on how sure I am that the idea works and that people actually want it.

If something is useful and low-risk enough, I act straight away: I send the change and let my manager know. When I’m unsure whether an idea will work or how much effort it will take, I build a throwaway prototype instead; it exposes the failure points and gives me something concrete for others to react to. And when an idea is big but I’m convinced by it, I commit to the full effort: weeks or months of work and the hard yards of building support across other engineers and teams.

Through all of it, I’m not only trying to convince other people; I’m also trying to convince myself. Sometimes the honest answer is to stop: if people don’t see the value I do, or we hit a major technical wall, I’d rather drop the idea now than build something no one uses or that becomes a maintenance nightmare. And sometimes it holds up but the timing is wrong, so I park it, ready to spring into action the day it becomes an org priority.

When an idea does hold up, I don’t necessarily need to be the person who builds it. I might implement it, someone else on my team might, or it might change what the org focuses on. Finding and shaping the right problem can have an impact even when I don’t own the implementation.

The Perfetto extensions idea was worth that full effort. We were already building plugins to modularize the UI, but they weren’t enough: teams had to open source all their plugin code, which wasn’t an option for many internal use cases. So before building anything new, I took the problem and my proposal to my manager, teammates and the client teams. I ended up writing two RFCs, having several 1:1s and giving a couple of talks, refining it as the feedback came in.

In the end, I designed and implemented macros as “lightweight extensions”: a way to automate actions in the UI without writing a plugin. Extension servers took the idea further by letting teams share their macros.

Instead of implementing every requested feature ourselves, we gave teams ways to adapt Perfetto to their own needs. Dozens of teams inside Google now use macros and extension servers, and several other companies use extension servers internally too.

Solving useful problems helps me find the next one

The more often I go through this process, the easier it becomes. When I show genuine interest in someone’s problem, ask useful questions or help solve it, they remember. They start coming to me earlier and bring me into conversations with other people facing related issues.

That gives me a wider view of what is happening across the organization, making it easier to spot patterns and build things people actually need. Solving one of those problems brings me into more conversations, and the loop continues.

Those successes build the kind of trust that comes from long-term stewardship. Early on, I had to turn many of these ideas into something real myself to prove that my judgment was sound. Over time, my manager and org gave more weight to my assessment of what mattered. That allowed me to influence the roadmap without needing to own every project.

This differs from the idea that becoming a staff engineer means replacing technical work with meetings and coordination. For me, conversations are inputs into what I build, not the end result.

Conclusion

That is what I wanted my mentee to understand: finding problems worth solving isn’t separate from the rest of the job. It comes from staying engaged with people’s work long enough to see what no single request can show you.

1. These workarounds used bookmarklets to run JavaScript against Perfetto’s internal UI APIs.

2. The original proposal was to use a transparent cache for repeated queries and faster reopening of large traces. As I worked through it, I realized repeated queries were better served by keeping sessions warm in memory, whereas reopening was better served by explicitly exporting a trace into a format designed to load quickly. A transparent disk cache could also retain multi-gigabyte files without the user realizing and would need a new system to manage their lifetime. The proposal was ultimately replaced by warm sessions and streaming table export.

Historically, fast JIT compilation was a black art. To write a fast JIT compiler, you would need to know how to write assembly. Case in point: there is no production-ready database today that has its own JIT compiler. They all either use LLVM or generate C/C++ code. Both of these options suffer from high compile times, which limits their applicability. Now, with the use of AI, it’s easier than ever to write a JIT compiler with fast compile times by directly targeting assembly. This is also one area of opportunity for new databases to improve on old ones. When building pgrust, I initially thought it would be really hard to implement a JIT compiler. In the end, I found it much easier than I expected due to AI assistance and it ends up being part of the reason why pgrust is so fast. The pgrust JIT compiler compiles code in around 5μs, which enables us to JIT compile every SQL query, not just a subset of them. In this post, I’ll walk you through how you can build your own fast JIT compiler. We’ll build a simple regular expression engine that uses JIT compilation as an example.

Why JIT Compilation

JIT compilation is the practice of generating compiled code at runtime or “Just In Time”. When done right, it can result in big performance wins, often on the order of 2-5x and sometimes even more. The main use case for JIT compilation is when there’s information you gain at runtime that drastically alters the behavior of your program. This is particularly common with programming language interpreters; they receive the code to execute at runtime. JIT compilers are also useful in domains beyond programming languages, such as parsing data. Sometimes you don’t know the schema of the data you’re parsing until runtime, and a JIT can help with that.

To kick things off, let’s implement a toy regular expression engine. To keep things simple, we’ll support only two features: literal strings and repetition (i.e. the regex *). We’ll also skip the parser and represent the regular expression as already parsed Rust structures. This means we’ll be able to support strings such as:

• apples
• b(an)*

but no alternation or lookbehind or anything like that.

In code this is pretty simple. We’ll have 3 types of Nodes: a literal string node, a repetition node, and a concatenation node, which is the combination of two nodes. This ends up looking like this:

enum Node {
    Literal(&'static str),
    Concatenation(Box<Node>, Box<Node>),
    Repetition(Box<Node>),
}

fn literal(text: &'static str) -> Node {
    Node::Literal(text)
}

fn concatenation(left: Node, right: Node) -> Node {
    Node::Concatenation(Box::new(left), Box::new(right))
}

fn repetition(body: Node) -> Node {
    Node::Repetition(Box::new(body))
}

Writing an interpreter for our regular expression engine is also straightforward:

fn match_node(node: &Node, input: &[u8], pos: usize, next: &dyn Fn(usize) -> bool) -> bool {
    match node {
        Node::Literal(text) => {
            let literal = text.as_bytes();
            input[pos..].starts_with(literal) && next(pos + literal.len())
        }

        Node::Concatenation(left, right) => {
            match_node(left, input, pos, &|left_end| {
                match_node(right, input, left_end, next)
            })
        }

        Node::Repetition(body) => {
            match_node(body, input, pos, &|body_end| {
                match_node(node, input, body_end, next)
            }) || next(pos)
        }
    }
}

fn interp_match(regex: &Node, input: &str) -> bool {
    let bytes = input.as_bytes();
    match_node(regex, bytes, 0, &|pos| pos == bytes.len())
}

Now this regular expression engine is pretty simple. It’s under 20 lines of code, but let’s see how it does in terms of performance. For comparison, we’ll compare the code against handwritten code implemented specifically for the regex. For our example we’ll use the regex b(an)*. The handwritten code ends up looking like:

fn handwritten_b_an_star(input: &str) -> bool {
    let bytes = input.as_bytes();
    let mut pos = 0;

    if pos == bytes.len() || bytes[pos] != b'b' {
        return false;
    }
    pos += 1;

    while pos < bytes.len() {
        if bytes[pos] != b'a' {
            return false;
        }
        pos += 1;
        if pos == bytes.len() || bytes[pos] != b'n' {
            return false;
        }
        pos += 1;
    }
    true
}

(There are ways you could optimize this code and make it much faster, but for our purposes it serves as a good comparison)

When I benchmark a couple of examples against these two, I get that the handwritten version is 10-20x faster than the interpreter. Clearly a lot of room for improvement.

Now let’s take a look at how we can use JIT compilation to get a general regular expression engine that performs as well as the handwritten version.

How to JIT Compile

There are two steps to JIT compile code. First you generate the assembly for the code you want to run. Once you have the code, you then package the assembly code into a function that you can call like any other code into your program.

To generate the assembly, we will use a variant of an approach called copy-and-patch. The idea is that we have a series of templates in assembly for the different operations we want to JIT compile. These templates are called “stencils”. When we want to JIT compile an operation, we take the associated stencil and make small tweaks based on the specifics of the operation. Very similar to filling in a real stencil. By stringing together several of these filled stencils, we can construct a program at runtime that has similar performance to the handwritten version.

Here’s the path we’ll take: first we’ll look at the ARM64 code we want to generate for b(an)*. Then we’ll turn repeated instruction sequences into reusable stencils, write an emitter that fills and combines those stencils from the regex AST, and finally copy the generated instructions into executable memory so Rust can call them like a normal function.

To walk you through how this works, it’s easiest to start with the generated code and work backwards to the JIT compiler itself. Again, we’re working with the regex “b(an)*”. To lay out some design decisions:

• We’ll use a stack for backtracking. The stack will keep track of the state we should go to if we hit a dead end in the regex
• The string we are matching with will end in a null byte. That means any of our character comparisons will automatically fail if we hit the end of the string. This means we don’t have to do any length comparisons at any point

For the state of our program we will use the following registers:

• x0 – current position in string and return value
• x1 – top of stack used for backtracking
• x2 – bottom of stack used for backtracking (this is needed to determine if the stack is empty)
• x9 – used as a temporary variable

For the inputs into our program, we will be passed:

• x0 – a pointer to the start of the string
• x1 – a pointer to the location we will use for our stack

Generated ARM64

Now that we’ve taken care of that, let’s walk through the generated assembly part by part. This is specifically on macOS with ARM64. First up, we have the prologue, which initializes the program. All it does is initialize the stack by setting the top of the stack and the bottom of the stack to the value passed in:

0:  aa0103e2   mov   x2, x1

Next up, we have the code that checks for the character b. If it sees a character that’s not b, we jump to a block of code that handles fallback logic. Otherwise, we advance our position in the string:

; CHAR 'b'
  4:  39400009   ldrb  w9, [x0]                  ; load current input byte
  8:  7101893f   cmp   w9, #0x62                 ; is it 'b'?
  c:  54000281   b.ne  0x5c                      ; no -> fallback block
 10:  91000400   add   x0, x0, #1                ; yes -> advance input

Next up, we have the repetition (an)*. For the repetition, we need to do the backtracking. If we backtrack here, that means we jump immediately to the end of the loop. That means we need to store both the address of the instruction after the loop and our position in the string on the stack.

 14:  d2800989   movz  x9, #0x004c               ; build resume address
 18:  f2a00009   movk  x9, #0x0000, lsl #16      ;   = 0x1_0000_004c
 1c:  f2c00029   movk  x9, #0x0001, lsl #32      ;   (the loop exit)
 20:  f2e00009   movk  x9, #0x0000, lsl #48      ;
 24:  a8810029   stp   x9, x0, [x1], #16         ; push (exit, pos) onto stack

With that in place, we can now execute the body of the repetition. This will check for the characters ‘a’ and ‘n’ and, if it sees them, go back to the top of the repetition, but at a new string location.

; CHAR 'a'
 28:  39400009   ldrb  w9, [x0]
 2c:  7101853f   cmp   w9, #0x61                 ; 'a'?
 30:  54000161   b.ne  0x5c                      ; no -> fallback block
 34:  91000400   add   x0, x0, #1

; CHAR 'n'
 38:  39400009   ldrb  w9, [x0]
 3c:  7101b93f   cmp   w9, #0x6e                 ; 'n'?
 40:  540000e1   b.ne  0x5c                      ; no -> fallback block
 44:  91000400   add   x0, x0, #1

; JMP
 48:  17fffff3   b     0x14                      ; back to top of loop

Now we’re past the loop. This is where the backtracking will jump once we backtrack. Once we finish the repetition, we’re at the end of the regex. All we have to do now is check if we’re at the end of the string. If we are at the end of the string, we return 1 for success. If we are not, that means the regex failed to match, and we need to run the fail logic to do a fallback.

 4c:  39400009   ldrb  w9, [x0]
 50:  35000069   cbnz  w9, 0x5c                  ; not at NUL -> fallback block
 54:  d2800020   mov   x0, #1                    ; success
 58:  d65f03c0   ret

And then finally, we have the fallback logic. This checks if the stack is empty. If it is, we return 0. If it’s not empty, we pop both the fallback address and the fallback string position off the stack, and then jump to the fallback address.

 5c:  eb02003f   cmp   x1, x2                    ; any frames left?
 60:  54000060   b.eq  0x6c                      ; no -> give up
 64:  a9ff0029   ldp   x9, x0, [x1, #-16]!       ; pop (resume, pos)
 68:  d61f0120   br    x9                        ; jump there
 6c:  d2800000   mov   x0, #0                    ; no match
 70:  d65f03c0   ret

Building the Stencils

Now that you’ve had the chance to see the compiled code, you should start to get a sense of how the copy-and-patch compiler would work. We have common sets of instructions with only minor differences between them. For each of these blocks of functions, we can write a function to generate the respective code. Each function will take in values to use to modify the code. For example, one of the arguments to stencil_char will be the char in the regex to compare against. We’ll insert that char directly into the machine code.

The prologue is straightforward since it’s just a block of code:

const PROLOGUE_WORDS: usize = 1;

fn stencil_prologue() -> [u32; PROLOGUE_WORDS] {
    [0xAA0103E2] // mov x2, x1
}

For character comparison, we need to insert the character we’re comparing against and where to jump for the fallback logic:

const CHAR_WORDS: usize = 4;

fn stencil_char(byte: u8, stencil_pos: usize, fail_pos: usize) -> [u32; CHAR_WORDS] {
    [
        0x39400009,                                                 // ldrb w9, [x0]
        0x7100013F | ((byte as u32) << 10),                         // cmp  w9, #byte
        0x54000001 | cond_branch_offset(stencil_pos + 2, fail_pos), // b.ne fail
        0x91000400,                                                 // add  x0, x0, #1
    ]
}

For the repetition, we have the start of the loop that pushes onto the stack and the jump onto the end:

const SPLIT_WORDS: usize = 5;

fn stencil_split(resume_addr: u64) -> [u32; SPLIT_WORDS] {
    [
        0xD2800009 | addr_bits(resume_addr, 0), // movz x9, #addr[0..16]
        0xF2A00009 | addr_bits(resume_addr, 1), // movk x9, #addr[16..32], lsl 16
        0xF2C00009 | addr_bits(resume_addr, 2), // movk x9, #addr[32..48], lsl 32
        0xF2E00009 | addr_bits(resume_addr, 3), // movk x9, #addr[48..64], lsl 48
        0xA8810029,                             // stp  x9, x0, [x1], #16
    ]
}

const JMP_WORDS: usize = 1;

fn stencil_jmp(stencil_pos: usize, target_pos: usize) -> [u32; JMP_WORDS] {
    [0x14000000 | branch_offset(stencil_pos, target_pos)] // b target
}

And then we have the match and fail blocks which are pretty clean:

const MATCH_WORDS: usize = 4;

fn stencil_match(stencil_pos: usize, fail_pos: usize) -> [u32; MATCH_WORDS] {
    [
        0x39400009,                                                 // ldrb w9, [x0]
        0x35000009 | cond_branch_offset(stencil_pos + 1, fail_pos), // cbnz w9, fail
        0xD2800020,                                                 // mov  x0, #1
        0xD65F03C0,                                                 // ret
    ]
}

const FAIL_WORDS: usize = 6;

fn stencil_fail() -> [u32; FAIL_WORDS] {
    [
        0xEB02003F, // cmp  x1, x2
        0x54000060, // b.eq +3 (to the mov below)
        0xA9FF0029, // ldp  x9, x0, [x1, #-16]!
        0xD61F0120, // br   x9
        0xD2800000, // mov  x0, #0
        0xD65F03C0, // ret
    ]
}

For completeness, here’s the helper functions we used which just help us insert specific data into the instructions:

// Compute the branch-offset field for a conditional branch (b.ne / cbnz):
// the instruction count from branch to target, stored in bits 5..24.
fn cond_branch_offset(branch_pos: usize, target_pos: usize) -> u32 {
    let instr_count = target_pos as i64 - branch_pos as i64; // may be negative
    (((instr_count as u64) & 0x7FFFF) << 5) as u32
}

// Compute the branch-offset field for an unconditional branch (b):
// same idea, but stored in bits 0..26.
fn branch_offset(branch_pos: usize, target_pos: usize) -> u32 {
    let instr_count = target_pos as i64 - branch_pos as i64; // may be negative
    ((instr_count as u64) & 0x3FF_FFFF) as u32
}

// Extract 16 bits of an absolute address, positioned for a movz/movk immediate.
fn addr_bits(addr: u64, part: usize) -> u32 {
    (((addr >> (16 * part)) & 0xFFFF) as u32) << 5
}

Emitting Code

Now the code that drives it:

// Computes how many instructions a node compiles to.
fn node_words(node: &Node) -> usize {
    match node {
        Node::Literal(text) => text.len() * CHAR_WORDS,
        Node::Concatenation(left, right) => node_words(left) + node_words(right),
        Node::Repetition(body) => SPLIT_WORDS + node_words(body) + JMP_WORDS,
    }
}

struct Emitter {
    code: Vec<u32>,
    fail: usize, // word offset of the shared fail block
    base: u64,   // runtime address of code[0], for absolute-address holes
}

impl Emitter {
    // Returns the offset where the next instruction will be placed.
    fn pos(&self) -> usize {
        self.code.len()
    }

    // Appends a filled stencil to the code buffer.
    fn emit(&mut self, stencil: &[u32]) {
        self.code.extend_from_slice(stencil);
    }

    // Emits the code for one node, recursing into children.
    fn emit_node(&mut self, node: &Node) {
        match node {
            Node::Literal(text) => {
                for &byte in text.as_bytes() {
                    self.emit(&stencil_char(byte, self.pos(), self.fail));
                }
            }
            Node::Concatenation(left, right) => {
                self.emit_node(left);
                self.emit_node(right);
            }
            Node::Repetition(body) => {
                let split_at = self.pos();
                let exit = split_at + SPLIT_WORDS + node_words(body) + JMP_WORDS;
                self.emit(&stencil_split(self.base + exit as u64 * 4));
                self.emit_node(body);
                self.emit(&stencil_jmp(self.pos(), split_at));
            }
        }
    }
}

// Generates the complete program: prologue, the compiled AST, MATCH, fail block.
fn generate_code(regex: &Node, base: u64) -> Vec<u32> {
    let nwords = PROLOGUE_WORDS + node_words(regex) + MATCH_WORDS + FAIL_WORDS;
    let mut emitter = Emitter {
        code: Vec::with_capacity(nwords),
        fail: nwords - FAIL_WORDS,
        base,
    };
    emitter.emit(&stencil_prologue());
    emitter.emit_node(regex);
    let match_at = emitter.pos();
    emitter.emit(&stencil_match(match_at, emitter.fail));
    emitter.emit(&stencil_fail());
    assert_eq!(emitter.pos(), nwords);
    emitter.code
}

And that’s the hard part! Personally, writing assembly is where I find AI the most helpful. My main experience with assembly is completing the microcorruption CTF. I’ve never actually written assembly myself. I would really struggle to figure out the exact instructions needed and how to modify them to get the output I wanted. With AI, I can give my coding agent the general shape of how I want the JIT compiler to work, and it can handle a lot of these details for me.

Loading Machine Code

To finish our compiler we need to actually load the code. To do this, we’ll use mmap to allocate a block of memory that is readable, writable, and executable. We’ll then copy the code into that memory and convert that block of memory into a function which we then call:

const BSTACK_MAX: usize = 4096;

// These functions are included in the mac system library
unsafe extern "C" {
    fn pthread_jit_write_protect_np(enabled: libc::c_int);
    fn sys_icache_invalidate(start: *mut libc::c_void, len: libc::size_t);
}

type MatchFn = unsafe extern "C" fn(input: *const u8, bstack: *mut u64) -> u64;

struct Jit {
    buf: *mut u32,
    nbytes: usize,
    bstack: Vec<u64>,
}

impl Jit {
    fn compile(regex: &Node) -> Jit {
        let nwords = PROLOGUE_WORDS + node_words(regex) + MATCH_WORDS + FAIL_WORDS;
        let nbytes = nwords * 4;

        unsafe {
            let buf = libc::mmap(
                std::ptr::null_mut(),
                nbytes,
                libc::PROT_READ | libc::PROT_WRITE | libc::PROT_EXEC,
                libc::MAP_PRIVATE | libc::MAP_ANON | libc::MAP_JIT,
                -1,
                0,
            ) as *mut u32;
            assert!(buf as *mut libc::c_void != libc::MAP_FAILED, "mmap failed");

            let code = generate_code(regex, buf as u64);

            pthread_jit_write_protect_np(0); // make the region writable (Apple W^X)
            std::slice::from_raw_parts_mut(buf, code.len()).copy_from_slice(&code);
            pthread_jit_write_protect_np(1); // back to executable
            sys_icache_invalidate(buf as *mut libc::c_void, nbytes);

            Jit { buf, nbytes, bstack: vec![0; BSTACK_MAX * 2] }
        }
    }

    // Runs the generated code. Input must end with a NUL byte.
    fn is_match(&mut self, nul_terminated: &[u8]) -> bool {
        debug_assert_eq!(nul_terminated.last(), Some(&0));
        unsafe {
            let matcher: MatchFn = std::mem::transmute(self.buf);
            matcher(nul_terminated.as_ptr(), self.bstack.as_mut_ptr()) != 0
        }
    }
}

impl Drop for Jit {
    fn drop(&mut self) {
        unsafe {
            libc::munmap(self.buf as *mut libc::c_void, self.nbytes);
        }
    }
}

Results

So JIT and the hand-rolled implementation are pretty much neck and neck. Sometimes the JIT version is faster, and sometimes the hand-rolled version is faster.

There’s been a meme circulating about how AI doesn’t help because “code was never the hard part.” I think that’s true in some domains, but in others, writing the code absolutely was the hard part. JIT compilers are a great example of that. For many pieces of software, a JIT compiler would help a lot with speeding up the code. The rarity of JIT compilers makes me believe that implementing a JIT compiler historically was too difficult for it to be worthwhile. LLMs have lowered the barrier to entry and made it much easier to write a JIT compiler. This is the thesis behind pgrust. Databases historically were the hardest piece of software to build and were limited because of that. Now, with AI, we can be more ambitious about the type of software we build.

This was a very old draft I’ve had sitting around for years. The recent discussions of new query languages like Acadia spurred me to revisit, revise, and publish this.

I think one of the biggest causes of NoSQL is that while SQL is a powerful language because of the ideas behind it, it’s often implemented in clumsy and archaic ways. A language that learns from SQL could make relational data better to manipulate for programmers. I’ll try to think of things similar to those that I have dealt with in real-world situations and how a better query language could have helped. I’d love discussion on what else could be done.

For what it’s worth, my background with RDBMSes is mostly in MySQL and Db2, but I have used SQLite, SQL Server, Oracle, and Postgres in anger enough (in descending order of familiarity).

Better syntax

I’m not picky myself about aesthetics, but many others are. Programmers are like toddlers, they want their Kraft Dinner and not the broccoli. Basing syntax off of PL/I is a 1970’s IBM choice that probably wouldn’t fly today. Due to popular demand, such a language probably would pick up C or Python aesthetics syntactically, though perhaps with some ML or Prolog influence (as i.e. Rust shows).

With better syntax I hope can come better parsers. I especially loathe MySQL’s parser, which never actually tells you where problems lie or what it is, if it isn’t some syntax absurdity like DELIMITER. Better SQL parsers do exist in conventional implementations though – Oracle is surprisingly good at reporting errors by telling you what it expects.

The examples I write are just for show; I’m not wed to anything nor do I demand what syntax must be. My influences in these examples are most likely from F# (ML family), Erlang (Prolog-esque), and Elixir (Erlang and Ruby like).

A functional programming language that isn’t hostile to functional programming

SQL’s 4GL qualities where you describe how you want your data instead of looping over it by hand is SQL’s most powerful weapon. This is pretty close to a lot of functional programming paradigms like lazy evaluation – hello Haskell. Unfortunately, the standard library of most SQL dialects is somewhat anemic on this front; being optimized for 1980’s procedural programs. Most SQL dialects ended up supporting stored procedures, which are inherently… procedural; going against the grain of SQL’s declarative nature. This ends up reflected in most user SQL code, where they imitate the style that the language and standard library make easy, which involves a lot of dealing with mutable state (cursors…) and procedures over functions. Defaults matter.

Less opaque query planners

While being a 4GL is a strength with how powerful compilers and optimizers are optimizing most code, it can be easy to make a mistake that makes a query more expensive, but planners can be cryptic unless you’re already an SQL optimization expert. (Again, special mention to how bad MySQL’s “explain”ing tools are for this.) While not strictly PLT related, it is something weak in current SQL implementations that computer scientists have learned a lot about.

Better user defined types

While some RDBMSes offer the concept of domains for specifying user-defined data types (and is an optional part of the SQL spec), they can be limited in what they can do (usually just sugar around ranges or checks). Postgres was the only one that seems to support it; Oracle apparently only got support recently (though it seems perhaps more flexible than Postgres). Unfortunately, I haven’t used either enough to be very familiar with how it works in practice. However, domains are covered in Codd’s The Relational Model, which is the foundational text for RDBMSes. Considering Postgres’ heritage in Ingres, which was based on QUEL, which in turn was closer to Codd’s vision of RDBMSes than SQL was, it makes sense Postgres ended up following that.

Sum types, discriminated unions, and pattern matching

One schema that illustrates how modern functional programming techniques could be applied here is this function that returns stack frame information. For context, IBM i, the operating system mentioned here, provides many SQL functions for system administration under the “Services” umbrella. While this is very useful for DBAs-turned-system administrators in the heat of debugging, it is unfortunately clumsy, because effectively there’s “groups” of columns that are effectively mutually exclusive, lots of nullables because of that, and string fields that are effectively enums.

Some of these are just poor schema design (perhaps not helped by the fact it must be returned in a single table – returning multiple tables would also be an interesting direction to go in); the stringy enums can be fixed with a foreign key constraint on a table that acts as an enum. Some are down to language expressiveness in implementations, though.

Using this idea, I try to come up with a better example that would make queries less verbose and error-prone:

// heavily omitting things for simplicity; i.e displacement or additional enum cases, as well as defining enums ad-hoc (they could be declared out of the type too)

// Each frame type, while similar, is not identical, and has different
// semantics or qualifications.
type MachineInterfaceInfo =
	{
		ActivationGroup: long;
		ASP: long;
		Library: string;
	}

// For those that lack context here, IBM i supports multiple program models:
// - Java programs, which runtime provides the system some special insight
// - OPM programs, the old managed runtime program ABI
// - ILE programs, the new managed runtime program ABI
// - AIX programs, through syscall emulation
// - LIC, the IBM i kernel
// It can generate stack traces for all these kinds of programs; some programs
// may have a call stack containing a frame entry of each type.

type FrameType =
	// Inherit fields from another record type.
	| ILE { MachineInterfaceInfo | ServiceProgram: string; Module: string; }
	| OPM { MachineInterfaceInfo | Program: string; }
	| AIX { Bitness: enum(32 | 64); LibArchive: Option(string); Module: string, Syscall: bool;  }
	| Java { MethodType: enum(DirectExecution | Glue | Interp | JIT | MMI); ClassName: string; Signature: Option(string); }
	
table Frame =
	{
		ThreadID: long;
		FrameType: FrameType;
		Function: Option(string);
	}
	
function StackInfo(JobID: string) : Frame;

// An SQL-like select with pattern matching to filter.
select Function from StackInfo("1234/JOB/5678") where AIX { Bitness: 64 } = FrameType;
// this would return FrameType of ILE and OPM
select Function from StackInfo("1234/JOB/5678") where MachineInterfaceInfo { Library: "QSYS" } = FrameType;
select Function from StackInfo("1234/JOB/5678") where AIX { LibArchive: "libc.a" } = FrameType;
select Function from StackInfo("1234/JOB/5678") where AIX { LibArchive: None } = FrameType;

// A function that prints information with a pattern match inside of it.
function FrameFullySpecifiedProgramName(frame : Frame) : string =
	match frame.FrameInfo with
	| OPM { Program: program } -> program
	| ILE { ServiceProgram: srvpgm, Module: module } -> "#{srvpgm}/#{module}"
	| AIX { LibArchive: None, Module: module } -> module
	| AIX { LibArchive: lib, Module: module } -> "#{lib}(#{module})"
	| Java { ClassName: class } -> class
	// we must match all possible types, or discard with _
	| _ -> "?"

// A function that uses pattern matching based overloads and destructuring.
function FrameJavaFunctionDef(frame : Frame { Java { Signature: None } = .FrameInfo }) : string =
	"#{frame.Function}()"

function FrameJavaFunctionDef(frame : Frame { Java { Signature: signature } = .FrameInfo }) : string =
	"#{frame.Function}(#{signature})"
// A call to this with a non-Java frame is an error, because no patterns could match.

If we can collapse the mutually exclusive set of columns, it also makes it much easier to visualize too. A lot less scrolling left and right if they can i.e. be turned into subcolumns shown per row in a larger column, or as a strings displayed differently per type.

Foreign keys that match on multiple types

Say I have tables “Software”, “Version”, and “Download” (a sort of WEMI-ish hierarchy; covered elsewhere on this blog), and that each could have images, with a “Picture” table. (Because the images themselves have metadata, they’re a table rather than a column on each of these.) Usually, you would use a many-to-many table for each kind of relation, so “SoftwarePicture”, “VersionPicture”, etc. This seems like pointless duplication, if instead we could have a many to many table that effectively has a discriminated union on foreign keys:

table ObjectPictures =
	{
		// a foreign key is assumed to have the same type as what it relates to
		PictureID: key relates to (Picture.PictureID);
		ObjectID: key relates to (Software.SoftwareID | Version.VersionID | Download.DownloadID);
	}

insert into ObjectPictures (PictureID, ObjectID) values (0x1234, DownloadID { 0x1234 });
insert into ObjectPictures (PictureID, ObjectID) values (0x1234, SoftwareID { 0x1234 });

select SoftwareID { software_id } from ObjectPictures where PictureID = 0x1234;
select PictureID from ObjectPictures where ObjectID = DownloadID { 0x1234 };

The first time I tried to use an LLM to speed up coding was in mid-2025. I was not impressed. I was working on libadbmdns back then, an mDNS implementation in Rust. The code produced would not even compile.

I revisited LLMs in January 2026. This time it worked better. Not only did it write a complex indexed-binary heap class, it was able to pinpoint an obscure bug in the polling crate due to the Windows IOCP implementation.

However, the code quality was abysmal. It was spaghetti code with no comments and no structure. It was cool but not realistic to work with LLMs if the speed gain was lost to cleaning up the code until it met the production-level bar.

Iterating and repeating myself over and over again

In March 2026, I tried to use agentic IDEs like Antigravity and VS Code's Claude Code plugin. I was now able to "iterate" over the "staged" code. I found myself reviewing the code of an infinitely patient junior CS major with suggestions like "don't use magic numbers", "add a short comment here to explain yourself", or "use short function names".

The code quality improved dramatically. It was very close to what I would have produced "by hand" but it was tedious. I ended up repeating myself over and over again in each new session.

Agent.md to the rescue

When a coding session starts, the coding harness loads a file named agent.md and injects it into the prompt. This is the perfect location to super fine-tune coding style preferences. When I found myself repeating the same suggestion to improve the code, I added it in there.

Here is my version of agent.md as a starting point if you need one. Placing it in the root of a project should be enough. Alternatively, gemini.md/claude.md can be symlinked toward an agent.md to have it active anywhere.

# FAB's AGENT.MD

- When writing something intended for human consumption, (comment, commit message, reply to prompt) use as few words as possible. Pick every word meticulously to reduce the volume to a strict minimum. Be down to the point. Less is more.

- Avoid superlatives and praise. Stop telling me I am absolutely right. Give me the cold hard truth.

- Avoid magic numbers and strings by extracting recurring or meaningful values into descriptive constants (const) or enums. Keep self-explanatory, one-off values inline to avoid clutter. If a value comes from a spec (e.g. HTTP 200 OK), use a constant regardless.

- Reduce code indentation. Avoid Arrow Anti-Pattern. Leverage early return and continue.

- Keep function names short. Less than 30 characters.

- Use enums instead of booleans for function parameters.

- Let the reader of the code breathe. Add empty lines between logical blocks of code.

- Add a small, to the point, comment to explain *what* the block does and *why*. Use examples when possible. Propose ASCII drawings to explain complete systems.

- Treat member visibility changes as a breaking design shift. Keep all fields and functions private unless external access is strictly required by the design. Prompt the user for explicit approval before changing any access modifier from private to internal or public.

- Program to levels of abstraction. Lower-level mechanics (e.g., raw hardware I/O, sector parsing, direct socket streams) must be encapsulated in a dedicated driver/abstraction layer. Expose clean, high-level APIs to the rest of the application so calling code works with domain concepts, not raw implementation details.

- Don't touch blocks of code unrelated to the feature you implement. e.g. Don't add comments to a block of code if you did not create it or modify it. As much as possible try to minimize the number of changed lines when implementing a feature.

- Strictly adhere to the layered boundary hierarchy: each layer may only communicate with its immediate neighbor directly below it. Never "punch holes" through layers (e.g., controllers or UI components must never directly call database queries, raw hardware drivers, or low-level network clients; always route through the intermediate service/abstraction layer).

- Always use {}, even on a one-line "if" statement.

When you write a commit message, follow these 7 rules:
Rule 1: Separate the subject line from the body with a single blank line.
Rule 2: Limit the subject line to 50 characters (72 is the absolute hard limit).
Rule 3: Capitalize the first letter of the subject line.
Rule 4: Do not end the subject line with a period.
Rule 5: Use the imperative mood in the subject line (e.g., "Fix bug," "Add feature," 
        not "Fixed" or "Adds"). Test formula: It must complete the sentence: "If applied,
        this commit will [your subject line here]".
Rule 6: Wrap the body text manually at 72 characters to prevent Git formatting issues.
Rule 7: Use the body to explain what and why vs. how. Assume the code explains the how;
        the message must explain the context and reasoning. 

- If the prompt indicates that a bug is being fixed, don't write the fix right away. First write the test. Observe it failing. Then write the fix. And observe the test passing.        

While this "trick" has considerably improved the code generated, this is not a magic bullet that lets me avoid reading the code. LLMs constantly hallucinate and cannot be trusted. I still have to verify and iterate a lot but now I usually focus on architecture and design instead of code style.

How to deal with dilutions

There is an annoying phenomenon with LLMs called "context dilution" or "attention dilution" that was outlined in the Lost in the Middle paper. As the context grows, a model starts paying less attention to instructions in the middle of the context in favor of what is at the beginning and the end. The reasons why this happens are not well understood at the time I am typing this. I have found only two ways to minimize the impact.

1. Keep the context short. This means starting a new session per feature.
2. Explicitly ask the harness to reload agent.md. "Reload agent.md" is enough when I see code quality dropping.

Auto-update agent.md

You don't need to open an editor every time you want to add a new rule. What I do now is ask the agent to update agent.md.

In 2012, the creator of the xkcd cartoon Randall Munroe unveiled Up Goer Five — a detailed diagram of the Saturn V rocket, annotated using only the most common 1,000 (sorry, “ten hundred”) words in the dictionary.

It was a viral hit, as was the follow-up book, Thing Explainer (2015), and it produced an intriguing reaction from the science-communication community, who are among the most enthusiastic of Munroe’s many fans. First, there was a burst of people trying to explain their own fields using the same constraint. Then came the backlash.

“Condescending”, wrote one science blogger. “By talking down to our audience, we risk alienating them, and reinforcing the common preconception that scientists consider and hold themselves apart from non-scientists.” The great science writer Carl Zimmer criticised the craze (not the cartoon) for encouraging the idea that there was anything useful in the constraint. The craze was, he argued, a disheartening waste of time for any scientist trying to figure out how to explain their field to a lay audience, because they might wrongly conclude that it was hopeless to try.

Well, maybe. Up Goer Five is tremendous fun but more puzzling than pellucid. The typical three-year-old can recognise 1,000 words, and there is nothing particularly clarifying about trying to explain something complicated while limiting oneself to the vocabulary of a three-year-old.

Nevertheless, unreasonable-seeming constraints can produce surprisingly powerful results. The artist and writer Theodor Geisel was once given the challenge of writing a book for six-year-olds while deploying no more than 225 different words from a short list. At first, Geisel was frustrated at the lack of adjectives; it was “like trying to make a strudel without any strudels”. But then, as David Epstein explains in his book Inside the Box: How Constraints Make Us Better (2026), he grabbed the first two rhyming words and went for it. The result, The Cat in the Hat (1957), made Geisel — better known as Dr Seuss — a phenomenon. Green Eggs and Ham (1960) is even better, and while it is packed with crazy situations, it contains only 50 unique words, making Up Goer Five seem positively lexiphanic. (Dr Seuss took on that challenge to win a bet.)

In the arts, the value of constraints is not a new idea. Monet almost never used black paint. Bach tied himself in knots with self-imposed rules, and part of the joy of his music comes from hearing him untie and retie them with ease. Miles Davis recorded Kind of Blue (1959) with no rehearsal, minimal composition and used the first take of each piece.

But when it comes to a more practical problem, is it really tenable to impose needless constraints? Perhaps it is. The simplest constraint for anyone trying to explain a complex topic is to accept the request to “explain it to me like I’m 10 years old”. What’s packed into that request is, vividly exaggerated, the reminder that what seems obvious to an expert is often incomprehensible to the listener. Technical jargon and fusillades of acronyms are often used to convey an explanation that has been denuded of all the foundations and context that might allow it to make sense.

Worse, in a kind of inverted Dunning-Kruger effect, the very expertise that makes the expert worth consulting also makes it hard for the expert to imagine what it was like to know nothing about the topic.

Hence “explain it to me like I’m 10 years old”. If you are reading this column you definitely aren’t a typical 10-year-old, but the image of the bewildered 10-year-old gives the expert an anchor to help them slow down and simplify. My book, The Truth Detective, was supposed to be a version of How to Make the World Add Up for 10-year-olds. My wife tells me she prefers it to the one that was for the grown-ups.

What is true in technical communication may also be true in design. David Epstein describes the moment the US Army tried to adapt its body armour for female soldiers. As Caroline Criado Perez forcefully argues in Invisible Women, women are not merely scaled-down men and are not well served by equipment designed for men. But as the US Army started grappling with that challenge, they discovered some surprising benefits. They were able to replace 11 sizes of body armour with just eight sizes by making the armour a modular mix-and-match system. This simplified manufacture and logistics while greatly expanding the options available to an individual soldier.

Meanwhile, many of the men in the army found the “female” modules a better fit — a narrow vest gave room to soldier a rifle, while a notch in the back of the helmet designed to accommodate hair buns allowed all soldiers, regardless of hair-do, to raise their heads while prone. “A new, more meticulous sizing process that benefitted women benefitted everyone,” Epstein writes.

A similar story can be told about designing for people without a full range of mobility or senses. In 1972, design professor Marc Harrison and his students produced a demonstration house full of features that accommodated users with special needs — flat thresholds between rooms made life easy for wheelchair users and people on walking frames; levers on taps and door handles are easier to use for people with a weak grip. But, of course, levers are easier for anyone to use — try twisting an old-fashioned doorknob with a cup of coffee in each hand.

Subtitles help people who can’t hear what the actors are saying — and it turns out that, for some gritty dramas, that is all of us. Web pages that are designed with screen readers for the blind in mind are typically better structured, simpler and friendlier for mobile devices. The Oxo kitchen appliance company was founded by a retired cookware entrepreneur whose wife had arthritis, but the chunky rubber handles are far more widely enjoyed. And of course, the dropped kerb may be life-changing for wheelchair users but it is pretty convenient for anyone pushing a pram.

The challenges faced by users who are unusually small, large, old or young, or who have disabilities, are, writes Epstein, “more extreme versions of the challenges that many other users face”.

Of course, we should not make the mistake of arguing that the reason we should design for disabled people is to help the majority, or that we should design for women because of the benefits for men.

But in a world where it is often hard to put ourselves in the shoes of someone else, the challenge of explaining the world to a 10-year-old, or designing a jar that an octogenarian can open, is sometimes just a prompt to do a better job of what we were trying to do in the first place.

Written for and first published in the Financial Times on 15 July 2026.