The Job Title Hides the Displacement

Employment data is a rear-view mirror. A company does not need to eliminate a role on the day an agent first performs part of it. It can stop backfilling departures, ask one person to cover a larger surface, cancel a planned hire, or move work to a different budget. The org chart looks stable while the demand underneath it is already shrinking.

That lag is why confident declarations on either side are premature. A steady number of developer jobs does not prove the work is protected. A dramatic demonstration does not prove an entire occupation disappears tomorrow. Both claims skip the mechanism between capability and payroll: the operating system that turns an agent's output into work a business can trust.

Our prediction is still blunt. Repeatable software-delivery work will leave human payrolls. The timing will differ by company because adoption is not a switch. It is a sequence of tasks becoming machine-runnable, machine-checkable, and eventually too inexpensive to justify assigning to a person by default.

A software engineer is not one activity. The title bundles clarification, decomposition, coding, testing, review, release coordination, incident response, and judgment about consequences. Those parts do not automate at the same rate. Coding can move first while approval stays human. Test generation can move while deciding what deserves testing remains a human choice. Monitoring can run continuously while escalation policy still belongs to the business.

The mistake is asking whether the whole bundle has vanished. Unbundle it. For every task, ask whether the input can be stated, the authority can be bounded, the result can be observed, and acceptance can be proved outside the worker's own account. When all four answers are yes, that task is a factory route waiting to be built.

This is not augmentation by default. If an agent performs a repeatable task faster, retains the procedure, and can run whenever work arrives, the business will not preserve the manual version for sentimental reasons. One person may gain leverage for a while. Once the system captures that leverage, the organization needs fewer people performing the underlying task.

Model access is not adoption. Giving every developer a coding assistant changes how text appears on a screen. It does not decide which request should run, what the agent may touch, how conflicting work is reconciled, or whether the result belongs in production. Without those controls, leaders are measuring tool use while people continue carrying every handoff and every consequence.

A factory changes the economics because it owns the route. It takes written intent, breaks it into bounded work, assigns workers, records state, enforces permissions, reproduces proof, and sends production evidence back into the next run. The model is one replaceable component. The durable asset is the machinery that lets accepted work continue without waiting for a particular person to clear a calendar.

That distinction explains why organizations can report widespread AI use without showing the full labor effect. Assistance leaves the human as the workflow. A factory removes the human from repeatable transitions. Until companies build the second system, they are testing capability without cashing in the operating change.

The first visible change will not be every engineer leaving at once. It will be a widening gap between people who choose destinations and systems that execute the path. Work that exists mainly to translate tickets, move status, produce routine code, repeat checks, or summarize what happened is exposed because its value is the transition itself. Transitions are exactly what a harness can retain and enforce.

Entry paths are exposed too. Companies have long used low-consequence implementation work to train judgment. When machines take that work, the old apprenticeship stops making economic sense before the need for experienced judgment disappears. Telling new engineers to learn the same routine tasks harder is not a strategy. Businesses will need deliberate ways to teach consequence, system design, and evaluation without pretending the training work still requires manual production.

Senior titles are not immunity. Experience matters when it changes the destination, the boundary, or the standard of proof. Experience that only makes someone faster at a repeatable route becomes factory knowledge. Once captured, it compounds inside the system instead of remaining attached to one employee.

You do not need a final economic verdict to act. Inventory the work moving through one repository. Separate destination-setting from repeatable execution. Choose one route with a clear input, limited authority, observable output, and independent acceptance gate. Build the route, measure what survives, and turn every rejection into a rule the next run must satisfy.

Then redesign roles around the decisions that remain. People should own product direction, acceptable consequences, exceptional authority, and the standards the factory cannot set for itself. Agents should perform the repeatable analysis, construction, checking, coordination, and monitoring inside those limits. Keeping a person in the middle merely because the old process had one preserves latency, not safety.

The public argument will keep swinging between mass displacement and harmless assistance because job counts are simple and operating systems are not. Do not let that argument set your schedule. The work changes first, the organization changes second, and the headline number arrives last. By the time the title disappears, the decision was made several factory routes ago.