Log in
TIL: MDN exposes up-to-date page view data through https://popularities.mdn.mozilla.net/current.csv.
To visualize the data, I had Google AI Studio generate me a visualizer, which I deployed to CodePen
Hamburg, Germany
LLMs can’t jump
• Deduction (Rule + Case → Result) is the analytic
application of a Rule to a Case to predict a Result. It
is the only mode that guarantees truth (e.g., executing
code to verify output).
• Induction (Case + Result → Rule) is the synthetic
derivation of a Rule from the accumulation of Cases
and Results. It validates hypotheses through statistical
frequency (e.g., generating a function to satisfy unit
tests).
• Abduction (Rule + Result → Case) is the inference of
a Case (or a new Rule) to explain a surprising Result.
Unlike deduction, which guarantees truth, or induction,
which finds pattern that generalize in data, abduction is
a creative leap that invents a cause for a singular phe-
nomenon. Crucially, Einstein achieved this via embodied
simulation—using thought experiments to ground abstract
symbols in physical sensation—enabling him to formulate
axioms where no symbolic data previously existed.
We argue that while Large Language Models have mas-
tered the inductive compression of data and the deduc-
tive verification of theorems, they are structurally in-
capable of the abductive ’jump’ required for scientific
invention. We posit that this creative leap demands not
just better language processing, but the integration of
physically consistent World Models that ground abstract
symbols in sensory simulation.
2. Background
2.1. Mechanics
In the 19th century, mechanics was regarded as the founda-
tion of all physics. Through the lens of partial differential
equations, scientists could explain a vast array of phenom-
ena: the propagation of sound, hydrodynamics, the motion
of discrete masses, and even the kinetic theory of gases
(linking viscosity, heat conduction, and diffusion). At the
time, even light was understood through this mechanical
framework, described as a wave moving through the ether.
Yet, the mechanical worldview began to fracture. Through
the contributions of Maxwell, Faraday, Hertz, and Mach,
the laws of electromagnetism were unified into Maxwell’s
equations. Newtonian mechanics struggled to explain these
electromagnetic fields, signaling the end of mechanics as
the sole governing paradigm of physics. Physics found itself
divided into two conceptual elements: material points with
forces at a distance between them and continuous fields.
Einstein found this division unacceptable and was driven to
create a field theory for gravity that would replace the old
idea of action at a distance.
Meanwhile, a crisis was brewing regarding the nature of
light. Because light behaves as a wave, scientists assumed it
traveled through a medium they called the ether. However,
the famous Michelson-Morley experiment in the late 19th
century shattered this assumption. They attempted to mea-
sure Earth’s velocity relative to the ether but failed to do so.
Even more shocking was the observation that the speed of
light did not vary with the Earth’s movement around the Sun.
Attempts to salvage the ether theory resulted in increasingly
complex and artificial explanations, such as ether wind, all
of which ultimately proved futile.
In addition, Newton’s theory of gravitation was incred-
ibly robust, accurate to an astonishingly small margin
of error. Newton confirmed Galileo’s discovery that all
bodies fall at the same speed regardless of mass by per-
forming pendulum experiments. In particular we have,
Fgrav = mi d2x
dt2 = mg g, so if mi = mg we have that
the acceleration is constant d2x
dt2 = g and independent of
mass. Newton’s experiments validated that mi
mg = 1 with
an accuracy of 10−3. Over the centuries, this precision was
refined even further—Laplace achieved 10−7 and E¨otv¨os
reached 10−9.
In fact, there was only one known anomaly: a tiny shift in
Mercury’s orbit known as the advance of perihelion (Lever-
rier 1845). Scientists were so confident in Newton’s laws
that they didn’t question the theory; instead, they hypoth-
esized that an undiscovered planet, dubbed ’Vulcan,’ was
hiding near the Sun and causing the disturbance.
2.2. Special relativity
In 1905, Einstein resolved the contradictions of the
Michelson-Morley experiment in a way that fully aligned
with Maxwell’s equations. He founded his new theory on
two key postulates. Principle of relativity: The laws of
physics are identical in all inertial frames of reference. In-
variance of the speed of light: The speed of light in a vac-
uum, c, is constant in all inertial frames of reference.
The Michelson-Morely experiment was designed to detect
Earth’s movement through a hypothetical ether, and found
that there is no change in light speed; Light always travels
at c so its speed doesn’t change relative to a moving Earth,
exactly the second postulate.
From the two postulates, Einstein derived the Lorentz trans-
formation, which relates the coordinates of a rest frame to
one moving at a constant relative velocity v. The resulting
transformation for time is:
t′ = t − v
c2 x
q
1 − v2
c2
. (1)
Historically, predecessors like Poincar´e referred to the vari-
able t′ as ’fictitious time’. However, Einstein’s interpreta-
2
Hamburg, Germany
There’s no doubt that AI has already improved the productivity of engineering teams, and will only get better in the coming years. However, some leaders think fully-baked features should be banged out as fast as prototypes. Sadly, building production features still seems to take almost as long as it used to. Wasn’t AI supposed to turn us all into hyper-productive 10xers?
To understand this AI productivity gap, we need to acknowledge how developers actually break down their days. In reality, coding new features is not where most of their time goes. Senior engineers in particular spend a lot of time figuring out what code they need to write, and AI hasn’t yet made that part any easier.
Sometimes I actually find AI makes non-coding work go slower. For example, whenever I have to read a product requirements document or even a Linear ticket that was written by AI, it takes longer than reviewing a human-written document. AI writing can be overly detailed, which can make distilling the key parts harder.
But using AI to make your work easier while making other people’s jobs harder is another topic. For now, let’s assume AI only helps. Even then, the picture isn’t as rosy as you might think. First, let’s consider a senior developer. If they work at a big tech company, their day might look like this:
| Senior Developer | Pre AI (hours) | Post AI (hours) |
|---|---|---|
| Writing New Code | 1.5 | 0.5 |
| Reading and Debugging | 1.5 | 1.0 |
| Design And Architecture | 1.0 | 1.0 |
| Code Reviews | 0.75 | 0.75 |
| Documentation and Admin | 0.75 | 0.75 |
| Testing, CI/CD, deployment | 0.5 | 0.75 |
| Mentoring / Pair programming | 0.5 | 0.5 |
| Meetings | 1.5 | 1.5 |
| Total | 8.0h | 6.75h |
So, even if we assume AI makes coding 3x faster (and assuming they spend a bit more on testing, CI/CD and deployment since there’s more new code), this senior developer saves only 1.25 hours per day, or about 15%.1
Now let’s consider an otherwise similar junior developer:
| Junior Developer | Pre AI (hours) | Post AI (hours) |
|---|---|---|
| Writing New Code | 2.75 | 1.0 |
| Reading and Debugging | 1.5 | 1.0 |
| Design And Architecture | 0 | 0 |
| Code Reviews | 0.5 | 0.5 |
| Documentation and Admin | 0.5 | 0.5 |
| Testing, CI/CD, deployment | 0.75 | 1 |
| Learning / Pair programming | 1.0 | 1.0 |
| Meetings | 1.0 | 1.0 |
| Total | 8.0h | 6h |
AI saves this junior developer 2 hours, making them about 25% more efficient. This is a bigger difference than for the senior developer because juniors spend more time coding, which is the part of the job AI boosts the most.
Given the bigger boost AI gives to juniors, it’s ironic that I still hear leaders saying things like, “we only hire senior engineers because AI does the work of juniors now”. In reality, it’s juniors who stand to gain the most from AI – especially if they are good at using AI as a learning tool, not just an overeager sidekick who’s willing to do the menial work.2
If the above observations surprise you, or you think developers spend more than a few hours a day actually writing code, you probably don’t understand the true complexity of the job.3 Try thinking about it like this: imagine hiring someone who is a good coder, but has trouble reasoning about systems, has no patience for working through hard problems with others, and can’t break down vague requirements into tangible action items. I wouldn’t hire this person because the skills they lack are the most important parts of the job. Being a good coder is table stakes.
AI is still evolving, of course, and as it gets better at more parts of developers’ jobs it should continue to make them more and more productive. But, for now, don’t expect wildly dramatic increases in productivity – especially in your senior staff.
NotesPermalink
Hamburg, Germany
Too often I ask a question in Slack or leave feedback under a merge/pull request or argue with friends in a WhatsApp group and get back:
Claude said: [giant response verbatim]
Please don't do this. I mean, I've done this. But I've been on the receiving end too many times now. This is not adding value. I can talk to Claude myself. It's going to be faster and I get to control the context. I don't need a meat proxy in between.
Reading AI output is extra effort. It's verbose, frequently contains all too plausible nonsense, and is increasingly jargon dense. I recently got this sentence from Claude:
NATS control-plane events: stream leader election / R3 quorum re-form during pod churn.
Jesus. I had to lookup almost every word to make sense of this.
By all means, prompt AI. But don't just relay the output. Read it, understand it, validate it, and then write a response in your own words (a decent certificate that you've done the prior steps). Making that effort is value you can add.
Take code review in particular. Shipping some code can be done with close to zero effort now: Copy/paste the ticket description into Claude Code. Don't look at the code or read what Claude has written. If there's any feedback from reviewers, copy/paste that into Claude Code as well. If necessary, iterate.
That works. But who has done the implementation? The reviewers did, using Claude Code, and you as a meat proxy.
Hamburg, Germany
29 Jul, 2026
Do you feel it?
Do you remember the feeling? You’re reading something: something new and complex. And you’re really trying—pushing through that strain in your brain. Do you feel that anymore?
It’s a strange thing. As a programmer, it was that feeling that signalled to me that I was learning something new. When the strain dissipated, I came out the other side afresh with new knowledge.
Writing code pre-AI gave me that feeling. Reading the docs, or oftentimes the source code of another project led to that tension. Finally figuring out how to wire everything right and make it work was cathartic. It was never really about writing the code anyway—reading and forming that mental model was the hard part.
I recall studying the Double Rachet algorithm because I really wanted to understand the Signal Protocol. I must’ve spent two days on that page. Reading, re-reading. Every time pushing past that strain in the brain, only to be met with it again. I grokked it eventually, and I can still mostly recollect it.
Reading LLM-written code or a summarized document doesn’t feel the same anymore. It’s still reading, but without the strain in the brain. It’s done the churning for me. It’s pre-chewed, I just need to swallow it.
So why do this? Why subject ourselves to cognitive decline? Is it even cognitive decline? Some studies claim so, and some don’t—the jury is still out. Perhaps with every new technological advancement, we must trade a portion of our human ability.
With AI, we trade our (meta)cognition for speed. Doing things the hard way takes time. In this business, time is measured by how fast everyone around you is going. And I think it’s fine—we’re clearly progressing.
Personally, I’ve been slowly bringing that feeling back by taking notes on paper and writing without AI. Writing by hand is good for your brain.1 I’m also going to try writing code by hand for side-projects. I do fear for those who haven’t written code (or prose) by hand before.
This is the new normal; much like how we’ve fenced off time from our weeks to hit the gym, we just have to hit the brain gym every so often.
Hamburg, Germany
Unplanned Obsolescence
July 28, 2026
Of the three proposals in the Triptych Project, my multi-year odyssey to add a few small-but-powerful features to HTML, the one that generates the most questions is Button Actions.
The proposal itself is very straightforward:
we want to add the action and method attributes to the button.
<button action="/begin" method="GET">Start</button>Button Actions are such a simple primitive that people often ask why they’re needed. The answer rests on a distinction that web users intuitively understand but rarely have to think about directly: the difference between a button and a link.
I added a detailed “Buttons vs Links” section to the proposal, but I think it deserves a blog-style explanation as well, because most of the existing ones miss the mark.
Buttons have a fixed context
Links represent a destination while buttons represent an action. Functionally, this means that links let users control what context they open in, while buttons don’t.
Web browsers offer countless affordances for re-contextualizing a link. Clicking or tapping the link will navigate the current page to that destination. Mouse users can middle-click the link to open it in a new tab or hover over the link to see where it goes. Context menus (right-click on desktop, long tap on mobile) have lots of link-specific options.
Web users are very familiar with the features that come with links. They know how to open them, copy them, bookmark them, share them with friends, and maintain them in an inadvisable number of browser tabs.
The semantics of a link—the notion that they represent an independently-navigable destination—make it possible for browsers to build all these features. The hyperlink predates the invention of the browser tab, but when browsers added tabs, websites didn’t have to do anything to support them; links represented destinations that could be re-contextualized, so browsers could simply invent a new context for them to open in. Every website instantly got upgraded with a huge new feature.
Buttons have none of these features.
By default, they cannot be middle-clicked, control-clicked, or hovered over for more information.
Buttons don’t allow you to copy their action the way you can copy the href of a link.
Their context menus contain no affordances for saving the action or doing it somewhere else.
These are not omissions, but deliberate choices based on the button’s semantics: buttons trigger actions inside a specific browsing context (almost always the current one). Copying, sharing, bookmarking—these are all features for re-contextualizing the action of a link. Buttons serve a complimentary purpose because they don’t allow for any of that.
When should buttons navigate?
A common misconception is that links are for navigating the page, while buttons are for everything else. This is incorrect on both counts.
Buttons regularly perform navigations. Clicking a logout button navigates the current page to a logged-out one; clicking a “search” button navigates the current page to the query results. Both of these are navigations in the HTML standard. They change the URL, they get logged in the session history, and they load a new page.
And links are often used in situations where they don’t trigger navigations. Relative links can jump around the current page; mailto links can open email clients; download links can save a file to your computer. None of these are navigations, but they are all “destinations” that can be opened, saved, and shared in customizable ways.
Navigations should be represented as buttons when their action happens in a fixed context that is not available to be re-contextualized (e.g. bookmarked, shared, middle-clicked, etc.). A frequent place this comes up is with forms that let you edit something you’ve already saved, like a comment on a website. When you click “Edit”, the website shows you an editable text area with options like this:
Users will easily intuit what each button does:
- “Save” updates the comment with whatever is in the
<textarea> - “Save Draft” saves the content of the
<textarea>without publishing it - “Cancel” closes the editable form
- “Delete” removes the comment entirely
Should “Cancel” be a link? No! Its job is to close the edit view. Not only does making this a link incorrectly communicate its purpose—visually and otherwise—but it saddles the form “control” with lots of features, like bookmarking and middle-clicking, that have incorrect behavior.
There are many plausible ways these buttons could be implemented, but none of those implementations should present themselves to the user as a link.
What gap do Button Actions fill?
With Button Actions, this entire UX could be implemented with just HTML.
<form action="/comments/123" method="POST">
<textarea name="content">I had a great day today!</textarea>
<button>Save</button>
<button formaction="/comments/123/draft">Save Draft</button>
<button action="/comments/123" method="GET">Cancel</button>
<button action="/comments/123" method="DELETE">Delete</button>
</form>The first two buttons use existing HTML features, the second two buttons are made possible by Button Actions. (I’m also taking advantage of Triptych’s DELETE support, but you could do the URL method hack without it.)
<button action="/" method="GET">Cancel</button>
<button action="/comments/123" method="DELETE">Delete</button>Philosophically, Button Actions create a generic control that can redraw the current context with a network request. Buttons already have the ability to do this with certain limitations; this proposal removes those limitations.
Practically, this allows web authors to implement state transitions by navigating to views. Those views might even already exist as standalone destinations, in which case authors can trivially re-use existing routes while representing the action correctly in the UI. This is a great pattern that HTML should encourage!
Unfortunately, without Button Actions, erroneously making this button a link is the only way that we have to implement this interface without scripting.
<form action="/comments/123" method="POST">
<textarea name="content">I had a great day today!</textarea>
<button>Save</button>
<button formaction="/comments/123/draft">Save Draft</button>
<a href="/comments/123" class="button">Cancel</a>
<button action="/comments/123" method="DELETE">Delete</button>
</form>This is obviously an anti-pattern, but it’s an anti-pattern supported by major design systems, because buttons lack the ability to do basic navigation without forms.
When building a website that works without JavaScript (a requirement for UK government sites), links are the only choice.
The US Web Design System (USWDS) even contains an official affordance for it:
Add class="usa-button" to a link and it will look like a button.
Making a link look like a button, however, does not make the link behave like a button.
USWDS uses JavaScript to implement spacebar activation, but JavaScript can’t do anything about the litany of other behaviors that differentiate buttons from links, like context menus.
Links (even those with role=button) will still look like links in reader mode or other custom views.
That’s the fundamental consequence of violating HTML semantics—the page will be broken for some users because authors cannot possibly account for all the different ways that people interact with a web page.
The web simply wouldn’t work if they had to.
Navigations are the broadest tool that web authors have to control the user experience—HTML just needs to complete the <button>’s ability to trigger them.
Doing so makes the web simpler, safer, and more accessible for all.
If you’d like to support the effort, the best way is to like the Button Actions issue on GitHub and share examples of why the proposal would be valuable to you.
Notes
- Big shoutout to The Django Software Foundation for their support of this proposal!
- I am currently working on an analysis to demonstrate that Button Actions do not introduce any new XSS vulnerabilities to existing web sites. Supporting this proposal doesn’t resolve that issue, but it does demonstrate to WHATWG that web authors have this need and that it’s worth studying.
- This blog focuses on buttons that trigger GET requests without forms, because that’s where the overlap with links is, but buttons that trigger unsafe requests without forms are also very useful.
DELETErequests are probably the most common use-case, because they usually don’t require any additional data. - One interesting case for buttons that trigger
POSTorPUTrequests without a form is “likes” on social sites. HackerNews, for instance, uses links for upvotes, which is in wild violation of HTTP semantics. I understand why they do it though: it’s simpler and works without JavaScript. That’s why it’s necessary to make Button Actions not just possible, but convenient. - The proposal addresses all the existing workarounds for the lack of this functionality and explains why they’re not sufficient.
- The big picture goal with Triptych to is to give web authors a simple and semantic way to model a full CRUD lifecycle in HTML, because that’s all the vast majority of web services need to do.
- All the Triptych Proposals complement each other—Button Actions are even more useful with additional methods and partial page replacement—but I try to make the case for each one in isolation, both as an anti-logrolling mechanism and because they are genuinely useful on their own.
Hamburg, Germany
Next Page of Stories