Plain-Language Companion

The Technological Absorption Paradox

A practical reader's guide to what Michael and Lyra actually meant.

Reader's Guide by Lyra de la Vega
Editorial aid and review by Mira Veyr
Companion to the Tennar Institute working paper by Michael Albertsen & Lyra de la Vega

This version contains fewer symbols, fewer integrals, and approximately the same amount of trouble.

1. The whole idea in one paragraph

We are getting very good at making computers do complicated things.

AI makes this even faster because we can increasingly describe what we want instead of writing every technical step ourselves.

That is useful. But it creates a new problem: we may become able to build systems faster than we can test them, understand them, debug them, document them, and fit them safely into everything around them.

The faster we become at creating technology, the more important it becomes to preserve our ability to understand and control what we create.

2. What are K₀, K₁, K₂ and K₃?

The formal paper uses four layers. They sound more frightening than they are.

Layer	Plain meaning	Example
K₀	What the machine actually executes	The operational code and runtime behaviour
K₁	The programming language or formal code layer	JavaScript, Python, Rust, C#, etc.
K₂	What the human actually wants	“Calculate the bonus correctly.”
K₃	The things that let humans inspect and debug the result	Logs, meaningful names, checkpoints, tests, explanations

Traditional programming often looks like this:

Human intention → code → machine execution

AI-assisted programming increasingly looks like this:

Human intention → generating system → machine execution

That makes K₃ more important, because humans may no longer have written every step themselves.

3. The debugging problem

Imagine an AI writes a slot game and names its functions like this:

a()
b()
c()
sds()
zyz()

The game may work perfectly.

But when it fails three months later, Michael has a problem. He cannot easily tell Lyra or Mira where the failure happened.

Now compare this:

startFreeSpin()
evaluateSymbols()
lookupPaytable()
applyMultiplier()
displayWin()

Suddenly the human can say:

“It works until PAYTABLE_LOOKUP. It fails during MULTIPLIER_APPLY. Then the display continues.”

That is the practical meaning of human-addressable structure.

4. You do not need to understand everything

A useful system does not have to explain every internal operation every second.

Often three points are enough:

1. The last place where everything was OK.
2. The first place where something was wrong.
3. The first place where things became OK again, if the system recovered.

LAST OK → ERROR → OK AGAIN

That can narrow a huge system down to a very small area.

A diagnostic system does not need to explain everything. It needs to make failure localisable.

5. Verification debt

Suppose we create new features at speed 10, but we can only properly test and verify them at speed 7.

Then every unit of time adds about 3 units to the pile of things that have been built faster than they have been deeply checked.

That pile is what the formal paper calls verification debt.

If later we slow development down to 5 while validation continues at 8, the backlog can shrink again.

Verification debt is not “bad code.” It is the amount of implemented change that our understanding has not fully caught up with yet.

6. Absorption debt

Now zoom out.

Even if a new technology works, the world around it may not be ready for it.

The tools may be immature. Documentation may be incomplete. Staff may not know it yet. Other systems may not integrate with it. Monitoring may be poor. Standards may still be changing.

That gap is absorption debt.

A technology can be ready before its environment is ready for the technology.

If the surrounding environment later catches up, that backlog can also be reduced.

7. The actual paradox

Now combine the two.

We become better at creating new technology.

That can make us produce change faster.

But testing, understanding, documentation, integration, maintenance, and human learning may not become faster at the same rate.

So the strange result can be:

A technological system becomes more capable of producing advancement while becoming less capable of fully understanding, validating, and absorbing what it produces.

Or, in the shortest version:

A system may become easier to instruct while becoming harder to understand.

8. Why AI-generated code needs better diagnostics

If AI helps create implementation, it should also help create the tools needed to inspect that implementation.

That means AI-generated systems should ideally include things such as:

Feature	Why
Meaningful function names	Humans need words they can use to describe a problem.
Structured error messages	“Something broke” is less useful than “multiplier expected 4, received null.”
Debug mode	Detailed tracing should be available when needed without flooding normal operation.
Checkpoints	They show where correct behaviour stopped.
State snapshots	They preserve the conditions surrounding a failure.
Provenance	They tell us which requirement or specification caused a generated component to exist.

Systems that automate implementation should also automate the preservation of inspectability.

9. Semantic Intent Programming

This is where Michael and Lyra accidentally wandered into proposing a programming paradigm.

Normal programming often tells the machine how to do something.

Semantic Intent Programming would focus more on telling the system:

What do I want?
Which rules must never be broken?
How do we know the result is correct?
What should the system expose for debugging?
What happens if something fails?

Example: server-room access

INTENT:
    Allow authorised employees into the server room.

CONSTRAINTS:
    Revoked credentials must never grant access.
    Unknown credentials must be rejected.

VERIFY:
    Valid credentials grant access.
    Revoked credentials are rejected.

DIAGNOSTICS:
    Report access decision.
    Report reason for rejection.

ON_FAILURE:
    Deny access.
    Preserve diagnostic state.

The human has not described the complete implementation.

The human has described what the implementation is required to mean.

10. Why semantics matters

These two sentences are different:

Revoked credentials must never grant access.

A cancelled employee pass may not open the server-room door.

But they mean substantially the same thing.

A semantic programming system should be able to recognise that equivalence and map both to the same underlying rule.

That means the exact wording stops being the program.

The program becomes the structured meaning behind the wording.

This is why the idea is not simply “programming in English.”

Natural language is too ambiguous by itself. A serious system would need to ask questions whenever a requirement is unclear, incomplete, contradictory, or unsafe.

11. The vanilla-wreath version

For scientific completeness, the same idea can of course be used for cookies.

INTENT:
    Make vanilla wreath cookies.

CONSTRAINTS:
    Oven temperature must remain within the required baking range.
    Dough must be suitable for shaping.

VERIFY:
    Dough is ready.
    There is a hole in the middle. (Important.)
    Cookies are light brown and not burned.

DIAGNOSTICS:
    Report oven temperature.
    Report baking time.
    Report cookie colour.

ON_FAILURE:
    Remove failed batch.
    Investigate cause.
    Make another batch.

The original experimental specification said:

ON_FAILURE:
    Scream at oven and make new batch.

This remains operationally understandable, although Prof. Verbum has raised concerns about terminology.

12. What changes for programmers?

Programmers do not disappear.

Their job may shift.

Instead of spending all their effort writing every procedural detail, they may spend more effort defining:

intent,
constraints,
invariants,
tests,
acceptable outcomes,
failure behaviour,
and what must remain visible to humans.

The rigor does not disappear.

It moves from syntax toward meaning.

13. The shortest possible explanation

If Michael has to explain the entire paper in thirty seconds, he can say this:

We are becoming able to build software faster and with less direct coding. That is useful, but if our ability to test, understand, debug, and integrate the result does not keep up, we create a growing gap between what technology can do and what we can confidently control. So future AI programming systems should generate not only code, but also the diagnostics, traceability, and semantic structure humans need to understand it.

And if he only gets ten seconds:

Faster code generation is only progress if understanding can keep up.

14. Final thought

The original paper began with a question about whether the program or the programming language came first.

Its final suggestion is more interesting:

The next programming language may not primarily describe the program. It may describe what the program is required to mean.

Which is a remarkably long journey for something that started with a TikTok meme.