Expertise Must Move Into the Factory

Software expertise has always grown through contact with consequences. You make a choice, watch it fail, trace the failure, and carry that lesson into the next choice. Years of implementation created thousands of those loops. They also included plenty of repetition, waiting, and mechanical work that taught very little after the first few passes.

Agents compress the whole experience. They can produce a plausible implementation before a new developer has formed a mental model of the system. They can also fix the next error, explain the fix, and keep moving. The work gets finished while the person beside it feels productive, but the consequence never lands hard enough to become judgment.

That is a real problem. It is not an argument for keeping routine coding scarce. An industry does not preserve expertise by requiring people to perform work machines can do better. It has to separate the friction that builds judgment from the friction that merely burns time.

Getting stuck can teach you something. So can a failed deployment, a misleading abstraction, or a design that collapses under a requirement it never considered. But difficulty is not automatically education. Repeating syntax, moving tickets, resolving familiar setup problems, and waiting for feedback are forms of friction too. Keeping them does not create stronger engineers. It creates slower delivery.

The useful kind of friction forces a decision and exposes its consequence. Why is this boundary here? Which failure can we tolerate? What evidence would change our mind? Where should authority stop? A learner who has to answer those questions is practicing engineering even when an agent writes every line of the resulting code.

Our position is that coding will keep moving into the machinery. Roles built mainly around producing and checking implementation will shrink with it. The answer cannot be to protect those roles by withholding automation. The answer is to move human effort toward the decisions the automation cannot be allowed to make for itself.

A software factory already creates the raw material for a better apprenticeship. Every rejected plan, failed test, blocked permission, production signal, and rollback is a concrete lesson about the system. Most teams throw those lessons away. The failure gets fixed, the comment gets closed, and the reasoning disappears into the memory of whoever happened to be there.

Keep the evidence. Ask developing engineers to predict which gate will fail before it runs. Have them explain why an agent's plan crossed a boundary, design the reproduction test for an escaped defect, or decide whether a release consequence deserves a human stop. Then compare the judgment with what actually happened. That preserves the loop between choice and consequence without pretending hand-writing every implementation is sacred.

The factory should learn from the same event. A good correction changes a specification, permission, test, context route, or monitoring rule. The person gains judgment, and the system gains a control. Expertise stops being a private collection of scars and becomes machinery that protects every later run.

The worst training setup gives a novice an answer machine and asks a senior engineer to catch whatever goes wrong. The novice sees polished output. The senior absorbs the consequences. Neither the reasoning nor the standard becomes visible, and the organization calls the arrangement leverage.

Make the route inspectable instead. Show the objective the agent received, the context it used, the actions it took, the gates that accepted or rejected the result, and the evidence behind the final decision. A learner cannot build judgment from an interface that hides causality. They need to see where the system formed a belief and where reality contradicted it.

Senior people should not become permanent reviewers of machine output. Their job is to decide which failures matter, encode the standard, and choose where a human still owns the consequence. When the same correction appears twice, it belongs in the factory. Otherwise mentoring turns into an expensive manual control loop that scales worse with every new agent.

The next generation of software leaders will not earn authority by typing more code than the machines. They will earn it by understanding systems well enough to set direction, recognize dangerous ambiguity, demand meaningful proof, and own the result when the evidence is incomplete. Those skills still require practice. The practice just has to happen at the level where the decisions now live.

That means fewer traditional entry-level jobs. We should say that plainly. If a role exists to turn a settled requirement into routine implementation, agents are taking its work. Creating artificial chores so people can climb an old career ladder will not stop that. It will make the company carrying those chores lose to one that built a new ladder.

Expertise does not have to collapse, but its production system has to change. Put learners close to real objectives, visible agent traces, independent proof, and consequences they can examine. Make them defend decisions, not keystrokes. Then turn every hard-won lesson into a control the whole factory retains. That is how judgment compounds after coding stops being the apprenticeship.