The Book of Hours

In the software companies of this decade, one job is currently disappearing, and hardly anyone notices: the bottom rung. Anyone in charge of engineering today has good reasons to no longer hire at the bottom — agents do the entry-level work faster, cheaper, and with a flawless audit trail. This decision is rational. For the quarter, it is even mandatory.

The industry debates this as a headcount issue. That is the wrong balance sheet. Entry-level work was never the actual product of these roles; their real product was never on any payroll: judgment.

Whoever shuts down this facility saves money in the short term. The bill for this will not be written later by HR. It will be issued by an industry paid to do the math: the insurers.

The children of the magenta

1997, a training room in Texas

Aviation learned this lesson earlier — and it has a tape of it.

Texas, 1997. An American Airlines training room, preserved as a recording whose copies still circulate through cockpit forums today. You hear the hiss of the tape, a room full of airline pilots laughing in the right places, and above it all the calm voice of Captain Warren VanderBurgh. He talks about Automation Dependency — about crews who, when surprised, keep programming when they should be flying.¹

On the navigation displays of modern commercial aircraft, the programmed flight path glows as a magenta line. VanderBurgh has a name for pilots who follow this line even when the situation has long demanded something else: children of the magenta. His therapy is uncomfortable and simple: When the automation surprises you, click it down one level. Fly it yourself. Keep the skill you will need on the day the line goes dark.

You can hardly watch this recording today without thinking of our own industry. We are currently laying magenta lines through every codebase, every workflow, every backlog — comfortable, precise, usually superior in standard situations. Aviation called its magenta children by name in 1997. We are currently hiring ours in batches and calling it efficiency.

The currency of judgment

Appreciation of a brutal ladder

Before we move on, a bow — and an objection.

First, the bow. The old software career ladder delivered. You climbed it yourself: first the boilerplate, then the bug fixes, then the reviews, eventually your first own module (an education, measured in a currency no bank carries — sleepless releases, inherited legacy code, survived migrations). Nobody called it a curriculum. It was one. Whoever spent ten years solving small problems under supervision ended up with something in their head that cannot be looked up anywhere: an intuition for where systems will break before they do. Seniority is crystallized experience from a thousand solved problems, paid for in hours.

Aviation keeps a ledger of the same currency, just more honestly. Every pilot owns a book of hours^{2; ratings, promotions, and the size of the insurance premium depend on its entries. Software never kept such a book. Our hours were in no column. They were hidden in the tickets, the diffs, the lost afternoons. They counted anyway.}

Now the objection, and it is justified: The old ladder was also brutal. It was gatekeeping with a luck factor — whoever got a good mentor moved up; whoever shoveled legacy tickets for three years dropped out. It paid learning time poorly, burned through learners, and weeded out talent that lacked patience for folklore. All true. That is exactly why nobody defends it today, and exactly why tearing it down meets so little resistance: Nobody stands up for a brutal ladder.

But the brutality of the ladder does not make its function expendable. You can tear down a bad system and still lose what it produced in the shadows.

We never loved the ladder. However, we also never asked what it manufactured on the side.

The double termination

One letter, two recipients

Neither the human nor the ladder has changed in the process — the work has migrated. The agents negotiating for their clients in the opening of this series, “The Foreign Service”, now write the code that entry-level professionals once used to learn on, taking over the tasks previously distributed at the bottom. And because a software company, once code becomes a commodity, ultimately sells its liability more than its features, the migration first hits the position invented to absorb liability. Looked at closely, this single process delivers two terminations.

The Job

Why nobody is hired at the bottom anymore

For their company, a junior was primarily a cheap shock absorber for the organization: hands whose mistakes stayed small enough to be absorbed, and whose successes could be logged as a team effort. This calculation carried the entry-level role through every budget round — regardless of whether anyone ever thought about training.

Agents do the same work with a log of every decision and a calculable error rate. This flips the budget round logic: The software shock absorber is cheaper than the salary one. What follows is quieter than any round of layoffs — jobs are not cut, they simply remain unposted. The market dries up from the bottom, cohort by cohort, without a single headline. The job disappears as a missing job ad.

The School

The curriculum that was never allowed to be one

With the same work, the second recipient of the letter disappears: the training room. Juniors never learned through courses. They learned through ten thousand incidental hours in which analytical thinking, observation skills, and the capacity for abstraction formed as a byproduct of routine work. The requirement to master these skills remains entirely intact — it is only the place where one could incidentally acquire them that has vanished.

The consequences arrive with a delay, and that is exactly what makes them dangerous. Based on my assessment from personal practice, it is about ten to fifteen years: the time it takes for missing juniors to turn into missing seniors. However, an early indicator should emerge long before the seniors are missing: teams that brilliantly generate options with agents while simultaneously becoming worse at deciding on one.^{3 The graveyard of variants then grows faster than the judgment needed to clear it.}

We are not just sawing at the ladder — we are sterilizing the expert pool of the future. Who is supposed to run the place in 2035 if nobody learned how the place works anymore?⁴

No hours, no rungs; no rungs, no seniors; no seniors, no liability.

What remains of the model

The third crack reaches those at the top

Two terminations, both addressed to the future. The third crack aims higher: It affects the present, and it affects those who reached the top a long time ago.

Prototyping was never just production, it was pathfinding: Whoever built a system piece by piece understood it, because every dead end mapped the terrain. The mental model of one's own software emerged as a byproduct of building — the same byproduct logic as with the junior, one floor up. Today, agentic pipelines generate solution spaces where no single path has been fully walked by a human anymore. Nobody ever completely held the theory of a single variant in their head; yet it was generated, tested, discarded, or merged anyway. What remains is a system that works, and a person in charge who can verify that without knowing it.

The software is no longer understood, only verified.

For a long time, this does not feel like a loss at all, and that is exactly the trap. The results are correct, after all. You feel competent because delivery happens — and only notice during an incident how much of that competence was borrowed. In the cockpit, this line was called magenta. In our editors, it is green, translates to “all tests passed,” and is just as comfortable.

Erosion, by the way, has a mirror side that is rarely mentioned. The user also maintains a mental model of what the software is and how it presents itself to them. If interfaces reassemble themselves dynamically in the future based on the situation, they lose their map too; erosion works on both sides of the same interface. This text stays on the inside.

The question remains: who signs the release for a system that everyone involved merely verifies? There is an industry that answers such questions neither culturally nor philosophically, but in premiums.

The actuaries

A bill nobody has sent yet

Insurers believe no presentation and no vision. They believe the statistics, because they pay for their own mistakes.^{5 In aviation, they have always priced the book of hours — how many hours, on which type, how current; this becomes a premium. For our industry, the same kind of invoice is only just sharpening its pencil.}

We are shifting from an economy of creation to one of responsibility; the work does not disappear, it condenses into the risky moment of approval.

The burden of proof still rests with the machine: It must show that it works more reliably than we do. On the day the actuaries read their statistics the other way around, this burden flips — Burden Inversion: Then whoever puts a human on tasks an agent demonstrably handles more reliably will have to justify it. In the language of risk models, there is a formula for this that is not in any policy today, yet is already becoming legible: statistically negligent staffing.

This is coming logic, not current law: Nobody insures at this rate yet. The direction, however, can be seen: Aviation openly discusses cockpits with only one pilot, and whoever listens to this debate always hears the premium question between the lines. An objection is obvious: Software is not a cockpit, people rarely die in our field. True — but the transfer applies to the learning economy, the gathering of hours, the preservation of the model, and precisely not the risk level.

Only when the actuary is in the room does a new ladder cease to be an HR idea and become a condition for survival.

The cross-check

The part that means you

Before you pass this condition on to your organization — to your hiring, your learning paths, your talent planning — pause for a moment.

You have read this text up to here as someone in charge: as someone who decides on juniors, budgets, and eventually policies. Meanwhile, you yourself have been working with the same systems for a good two years. You delegate, approve, verify. The diffs have gotten longer and your reading time shorter; the results are good, the pace is high, and tracing the steps increasingly feels like a luxury the calendar denies.

When was the last time you put an hour into the system you are responsible for — not as an approval, but working the material?

And what has become of your model?

The first answer

What two years of delegation do to a model

I will answer first, since I asked the question.

In the projects I work on daily myself, my model is still close — but it is blurrier and more short-lived than with code I conceived myself. In the pipeline behind my learning portal, things look different: a backlog of thousands of tickets that I stopped writing myself a long time ago; I talk to the dispatcher, the rest runs at night. My model of this code is in bad shape. Initially, I meticulously read every change. Since the Opus generation^{6 at the latest, I lack the feeling that I need to re-read — with coding guidelines, test-driven development, and reviews, good code simply comes out. It is now significantly more likely that a cleanly instructed Opus 4.8 on Max Effort finds a bug in my code than I do in theirs.7 Poorly instructed, the same machine vibecodes garbage just as reliably.}

The erosion, however, did not just stay in my head. Since I dictate almost everything, I type measurably worse — more typos, less precision in fingers that hit blindly for decades. That terrified me. The diagnosis is banal and eerie at the same time: The brain saves energy wherever it can. As soon as roughly hitting the mark is enough because a layer underneath catches everything, it lets the precision decay — the subconscious discontinues the services the conscious mind no longer demands. Counter-training helped: typing again where I could long dictate, manually correcting every typo, even where it was not necessary at all. It got better again.

Erosion is therefore trainable, just against the current. Whoever wants to keep their model needs hours that force it.

The new bottom rung

Where the ten thousand hours begin now

Which hours force a model when the old ones have migrated? The answer now carries a job title: Context Engineer — the profession that builds the workspace for agents: directives, tickets, audit trails, memory. Context instead of code.

The bottom rung of this ladder is called Directive Author, and it is more concrete than the title sounds. The beginner writes their first directive — for instance, the review rules of their team, formulated as instructions for an agent. On the first attempt, they fail because the instruction is too vague and the agent produces literal nonsense. On the second attempt, they fail the other way around: They regulate every individual case, and the directive suffocates exactly the decisions it was supposed to enable. The training lies in this oscillation. They learn to frame intent in a way that an alien intelligence can execute it; they learn to hold both poles at the same time — watertight yet lean; and they learn logical forensics, the reverse-reading of a thought trail back to the point where expectation and course diverged. These are the same muscles previously trained on boilerplate. Only the training equipment is new.

Above this are four more rungs: Ticket Designer, Review Operator, Lessons Learned Curator, Architecture Contributor. At the top, the object shifts — the experienced Context Engineer designs entire hierarchies: a supervising entity that holds principles above an executing one that delivers; an externalized conscious mind above a very diligent subconscious. Aviation institutionalized this same separation after its bitter years as Crew Resource Management^{8 — hierarchy that forces contradiction instead of rank.}

An earlier article in this series, “The Constitution of Software,” left open who actually authors this document. Here is the answer: What the Context Engineer writes is the constitution of the software. I walked this path myself — the directives, tickets, reviews, and curated lessons behind my learning portal basiswissen-ki.de are nothing else but my new book of hours.

The hours have not disappeared. They just changed currency.

The root

Where the new ladder gets its wood

It remains to be clarified where the people for this ladder are supposed to come from. The answer has been sitting in your org chart for twenty years, mostly underfunded: in the UX role.

The term requires a second of patience, because “UX Design” is burned as a word^{9 — too many years in which it stood for pixel pushing, wireframes, and making things pretty after the fact. What is meant is the role behind it: It starts with requirements and ends with evaluation, it encompasses research, analysis, conception, and assessment, and it talks to every other role in the house, down to sales. Its toolkit consists of five competencies: analytical thinking, communication, observation, abstraction, visualization.}

Read this list again next to the bottom rung from earlier. Framing intent precisely: communication and abstraction; reverse-reading thought trails: observation and analytical thinking; designing hierarchies: abstraction and visualization. The competence profile of the Context Engineer is not a new talent the job market has to wait for — it exists, across the board, under a false name. The UX role is supercharged by the new tools instead of replaced: UX Supercharged, if you need a sign for it.

From personal observation over ten years: Back then, the pure coder was the more resilient animal and the UXer was the luxury item you cut first in bad quarters. Today, this is reversing — the coder's tasks migrate into the agents, while the UXer's competencies become the prerequisite to lead these agents at all.

Two honesties belong here. First: A very capable requirements engineer and a very capable developer can take over parts of this work — that is partly true, and it remains true. Second: This rescue carries roles and does not save vested interests. The inversion affects tasks; whoever tied their identity to a task will not be helped by a new coat of paint. They are helped by a switch to the layer where their judgment makes the difference again.

This rescue is narrower than the industry hopes — and more viable than those affected believe.

Who owns the judgment

The balance sheet everything leads to

Let us draw out the line. When creation becomes a commodity, what cannot be generated remains a scarce good: judgment that stands accountable for its approvals. Liability becomes a balance sheet item — invisible in good years, crucial in a disruption. A company that stops the production of judgment today will in ten years sell something it no longer owns itself: the ability to be liable for its own software.

With this, the real question is in the room: Who owns the judgment? The model provider delivers capability, the policy delivers a price — neither delivers judgment. It belongs to the person who wrote the directives and can stand by them. Organizations that train such people own their judgment themselves; all others rent it until the landlord raises the rent.

Beneath this balance sheet lies something that does not appear in any quarterly report. People whose self-image reads “I am a good engineer” are currently watching machines reproduce their output — faster, cheaper^{10, tirelessly. A workforce that feels replaced behaves differently than one that feels augmented, regardless of any productivity metric. This is first a health issue and only then a labor market issue — but that will be its own article.}

The opening of this series, “The Foreign Service”, left a question at the time: which software company still exists at all in such a world. Here is the answer. Which company still exists? The one whose pipeline survives. And a pipeline consists of people.

1997, once more

What aviation did after the lecture

The 1997 tape simply runs out at the end. Whether there was applause is recorded nowhere. What is recorded is what aviation did afterward: It kept the automation and changed the training. It specified which hours a pilot must fly by hand so that their skill survives the day the line goes dark — new types of hours, entered in the same old book of hours. Their insurers priced in these entries, without sentimentality, as what they are: valuable substance.

Our industry is standing in its own 1997. The new ladder can be described, the bottom rung too — what is missing are the institutions that count such hours: curricula, learning paths, exams, a book of hours for Context Engineers. They are not built yet. Somebody will construct them, alongside the existing schools, faster than passing through them — but that is its own story.

Until then, the question for your company is simpler than it looks. Not whether you introduce agents — everyone does that. But whether someone still works at your place in 2035 who knows how the place runs. And has a book of hours that proves it.

1. The recording of the lecture “Children of the Magenta” (Captain Warren VanderBurgh, American Airlines, 1997) has been circulating publicly for years; this section owes its image and term to it. It remains worth watching today — even for people who will never see the inside of a cockpit.
2. Book of hours: in the Middle Ages a private prayer book that divided the day into fixed hours of prayer — one of the most widely used books of the Late Middle Ages; in aviation, the document in which every flown hour is logged. Both formats manage the same asset: a life, counted in hours. And in both cases, a higher authority reads along at the end.
3. An expectation, not a measurement — the pattern is plausible, but I have not observed it systematically.
4. More details in my book AI Fundamentals, Chapter 12 “Beyond_Tomorrow”.
5. Which distinguishes them from almost all other voices in this debate: Their opinion costs them their own money. Consultants are paid for optimism, conferences for reach — actuaries for hits.
6. While this text was being written, I had access to Fable, the generation above Opus, for two or three days — a brief, hurried peek through the keyhole at what is standing at the door. Then it was over: Fable was abruptly shut down for everyone by order of a US agency after a jailbreak was demonstrated. When you read this, the model is probably unreachable — the glance was enough, however, to sense that this here is not a final state, but an intermediate one.
7. Assessment from personal practice; sample size: one author. The author did keep track, however.
8. Crew Resource Management, abbreviated CRM — and no, not the software that maintains your sales contacts. Aviation meant almost the exact opposite of customer care with those same three letters: that the First Officer contradicts the Captain before the mountain gets closer.
9. UX Design: a job title that meant “make it pretty” for so long until its bearers stopped explaining what they actually do. The term can hardly be saved anymore. The role can.
10. “Cheaper” with an asterisk. The price holds as long as the tokens are subsidized — and a single feature can easily cost three figures via the API, properly billed, quickly even four figures. Viewed this way, the model is the SaaS solution: rented, metered, its price dependent on external quarterly goals. Tim from the next room, who runs on coffee instead of tokens, is the On-Premise variant — slower, but you know his invoice, and it does not double overnight.