Log in
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
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
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.
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.
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.
OpenDerm is an open-source robotic imaging system for creating high-resolution, reproducible 3D maps of the skin. Registered scans help reveal new lesions and identify subtle changes in existing ones.
The hardware designs, software, and build documentation are all openly available.
01 / THE PROBLEM
For melanoma, early detection can make the difference between a highly treatable cancer and a life-threatening one.
More than 100,000 Americans are diagnosed with melanoma each year. This form of skin cancer has a five-year relative survival rate of nearly 100% when detected early, but about 34% after it reaches distant parts of the body.1 Approximately 30% of melanomas develop within an existing mole, while 70% appear as new lesions.2 In either case, the earliest visible sign may be small: a millimeter-scale change at the edge of a mole, a localized shift in its color or structure, or a new spot only a few millimeters across. Detecting changes at this scale requires a precise record of the skin’s prior appearance.
For people with many moles, detecting change requires tracking the entire skin surface over time. A clinician can examine the skin during an office visit, but without a standardized photographic baseline, determining whether one spot among hundreds is new or changing can be difficult. Total-body photography can provide this longitudinal record, but access to such systems remains very limited due to high costs and limited clinical evidence that existing systems reliably catch melanoma earlier than dermatologists.34
Improving total-body imaging requires progress in three areas:
01
Higher Resolution Imaging
Many existing total-body photography systems use wide fields of view to capture large areas of skin, but at the expense of fine detail. Detecting subtle changes in a lesion’s boundary, color, or internal structure requires higher-resolution images.
02
Longitudinal datasets
Most AI models for skin-cancer detection are trained on isolated images of lesions already identified as suspicious. These datasets therefore provide little evidence of how melanomas first emerge and evolve before drawing clinical attention. Training models to recognize earlier signs of melanoma will require repeated, high-resolution images of the same skin over time.
03
Frequent, accessible scanning
Total-body photography must become more affordable and widely available. Patients at high risk should be able to receive frequent, standardized scans.
A robotic imaging system offers a practical way to meet these requirements. By moving close to the body and following its contours, the system can maintain consistent distance, angle, focus, and lighting while capturing high-resolution images across the skin surface. Using a single camera with cheap actuators also reduces hardware cost compared with a large array of fixed cameras.
1. National Cancer Institute. SEER Cancer Stat Facts: Melanoma of the Skin. Estimated 2026 incidence; five-year relative survival based on SEER 21 data, 2016–2022. ↩
2. Pampena R, Kyrgidis A, Lallas A, et al. A meta-analysis of nevus-associated melanoma: Prevalence and practical implications. Journal of the American Academy of Dermatology. 2017;77(5):938–945.e4. ↩
3. Soyer HP, Jayasinghe D, Rodriguez-Acevedo AJ, et al. 3D Total-Body Photography in Patients at High Risk for Melanoma: A Randomized Clinical Trial. JAMA Dermatology. 2025;161(5):472–481. ↩
4. Lindsay D, Soyer HP, Janda M, et al. Cost-Effectiveness Analysis of 3D Total-Body Photography for People at High Risk of Melanoma. JAMA Dermatology. 2025;161(5):482–489. ↩
02 / THE HARDWARE
The Robot
OpenDerm is built primarily from off-the-shelf parts. The video below shows the assembled prototype running a capture sequence at 20× speed.
The gantry moves the camera through four degrees of freedom. Three linear axes position the sensor head within the workspace: X travels along the side rails, Y moves across the top beam, and Z sets the camera height. A rotary axis (RX) tilts the sensor head to align the camera with the skin surface.
X Long travel Y Cross travel Z Vertical travel RX Pan rotation OpenDerm · 4-DOF gantry
The sensor head carries a Canon EOS R7 with an RF 100 mm macro lens, a Godox MF-R76 ring flash fitted with a cross-polarization filter that reduces specular glare, and two downward-facing laser distance sensors. The distance measurements allow the control system to maintain a consistent working distance and camera orientation relative to the skin.
Canon EOS R7 Canon RF 100mm lens Godox MF-R76 Flash +Cross Polarization Filter ×2 laser distance sensors OpenDerm · sensor head
03 / THE SCANS
High-resolution skin imaging
5 mm
OpenDerm captures skin at 78 pixels per millimeter, resolving details such as a mole’s pigment network and nearby individual hairs. In the interactive viewer, you can explore two registered 3D scans and inspect the lesions measured and matched across them.
HOW IT WORKS
How OpenDerm builds a 3D skin map
At each imaging station, the robot uses two laser sensors to control the camera’s angle and working distance before capturing a high-resolution photograph. The complete pipeline then aligns the overlapping images and reconstructs them as one continuous surface.
EOS R7 + macro lens
rx tilt joint
laser #1
laser #2
laser beams · 110 mm standoff
one frame · 91 × 61 mm
skin
04 / COMPARE APPROACHES
High-resolution imaging at a lower cost
Total-body photography remains an emerging field, with limited clinical availability in the United States and many systems still experimental or under development. Three main approaches have emerged for imaging large areas of skin: wide-field total-body photography, close-range robotic scanning, and guided smartphone imaging. Each involves different trade-offs in speed, detail, consistency, footprint, and cost.
OpenDerm captures skin at 78 pixels per millimeter using less than $8,500 in hardware. It is fully open source and provides some of the highest-resolution imaging available at a fraction of the cost of commercial total-body photography systems.
Approach 01
Wide-field total-body photography
Wide-field systems photograph large areas of the body from a distance, either with an array of fixed cameras or a single camera repositioned automatically between views. They provide standardized whole-body records, but individual lesions may require separate close-up or dermoscopic imaging.
SecondsWide-field detail$$$
Examples: Neko · Canfield VECTRA · DermSpectra · FotoFinder
Wide-field capture · fixed-array example
Approach 02
Close-range robotic scanners
A high-resolution camera mounted on a robotic arm or gantry moves close to the skin and systematically across the body while maintaining a controlled distance and viewing angle. Imaging the skin region by region allows a single camera to capture much finer detail than a distant wide-field system, while requiring less space and camera hardware. The trade-off is speed: the body must be scanned sequentially rather than all at once.
MinutesHigh-resolution detail$$
Examples: SquareMind · iToBoS · OpenDerm
Robotic scanner · one moving camera
Approach 03
Guided smartphone imaging
A smartphone application guides a patient, caregiver, or clinician through a standardized series of photographs. This approach requires little dedicated hardware and can be deployed almost anywhere. Its main limitations are image resolution and consistency: lighting, distance, pose, framing, and focus can vary between scans, making subtle longitudinal changes more difficult to measure reliably.
ManualVariable detailNo dedicated hardware$
Examples: SkinIO · MoleMap · Miiskin
Phone & app · guided capture