AI and the Future of Software Engineering: A New Path to Senior Engineer (Part Two)
In Part One, we explored how AI is subsuming mid-tier software engineering work—the reliable translation of specifications into code that once formed the backbone of the profession. We examined the statelessness problem that prevents AI from operating effectively on idiosyncratic codebases, and why standardization is the path forward. But standardization alone doesn’t solve the deeper crisis: if the traditional path from junior to senior engineer ran through years of mid-tier translation work, and that work is now automated, how do we develop the senior engineers who can effectively orchestrate AI? The answer lies in looking backward to move forward.
The Apprenticeship Model
The path from junior to senior engineer used to run through years of mid-tier translation work. Judgment was honed by doing—taking progressively harder tickets, absorbing patterns, building intuition about what worked and what didn’t. The work itself was the teacher.
In an AI-led world, that path is broken. The work that built engineers into senior engineers is now effectively automated. AI simultaneously magnifies the demand for senior engineers and destroys the pipeline to produce them. The market will eventually force a correction, but intentionality now avoids a painful adjustment later.
Doing so requires thinking beyond bootcamps, certifications, and other forms of training. The knowledge that distinguishes a senior engineer is tacit, contextual, and evolving. You recognize it when you see it but struggle to articulate it. It’s entangled with specific systems and their histories. The right answer this year might be wrong next year because the tools changed.
Humanity has consistently arrived at the same approach to solve this type of domain-heavy pipeline: apprenticeship. Working alongside someone who has it, watching what they do, trying it yourself under supervision, getting feedback when you get it wrong.
As an example, electricians are highly specialized and perform incredibly domain specific work. In fact, software engineers often leave the field to become electricians–and vice versa. They require similar aptitudes and even have similar compensation. Apprentices often work for years under licensed master electricians before working independently—learning by doing real work under supervision, not by simulation
Here’s a model for how this might work in practice:
Validation. The apprentice’s first job isn’t writing code—it’s reading AI-generated code and assessing whether it’s correct. This requires understanding intent, catching subtle bugs, recognizing when code technically satisfies the prompt but misses the point. It’s real oversight work, not make-work. And it’s developmental: the apprentice learns the codebase by reading it critically, building the mental map that used to come from years of writing.
Sandboxed generation. Once the apprentice can validate effectively, they start generating—but in bounded, low-risk environments. Isolated components, utility functions, test suites. They run the agentic flow themselves: prompting, providing context, reviewing output. The senior becomes the validator, and the apprentice learns from seeing what the senior catches.
Sub-agent rotation. Modern agentic workflows use subagents that perform specialized functions: PR review, test generation, security analysis, documentation. The apprentice rotates through these checkpoints as the human-in-the-loop, reviewing what AI produces at each stage. This teaches failure modes—the apprentice doing security review learns what vulnerabilities AI introduces—and builds system-level understanding from multiple angles.
Orchestration. The apprentice runs the whole flow, designing the scaffold, decomposing tasks, providing context, reviewing at the level that matters, knowing when to follow standards and when to deviate, documenting deviations as appropriate. This is approaching senior work and demonstrating capability of taking responsibility for system-level outcomes. This is often the phase where an apprentice transitions to journeyman, which may well be the closest equivalent to what we consider today to be a mid-tier software engineer.
This model requires seniors willing to teach and organizations willing to pay for it. That’s the historical failure mode of apprenticeship—it collapses when masters won’t invest in apprentices. Firms that want senior engineers will have to value and reward the seniors who develop them.
Failure to adopt this model will create a significant disruption in the availability of senior engineers in the job market and lead to an expensive, market-driven adjustment period.
The Master Engineer
In the trades, journeymen work independently, competently, but they don’t train apprentices and they don’t make the calls that shape how the shop operates. Typically they execute high value, high difficulty tasks that are broadly supervised by the master, while the master focuses on overall project success–and on training an apprentice along the way.
The orchestrator we described above—the journeyman—runs agentic workflows effectively, decomposing tasks, providing context, reviewing output, and shipping features. This is high value work, but it is not the work of a senior or “master” engineer.
The master engineer does something different. They maintain the system itself—not the code, but the context that makes the code possible.
Shaping the scaffold. AI can write code but can’t decide what code to write. Someone has to design how work gets decomposed, what context each task requires, where human judgment is necessary. This is architectural thinking applied to the process of building, not just the structure of what’s built.
Maintaining the record. When standards don’t apply, the master documents exceptions—not just what, but why. These annotations become shared context for future engineers and future AI sessions. The undocumented deviation is the cardinal sin; the well-documented exception is a contribution to the field.
Allocating human attention. Human attention is the scarce resource. The master decides where to spend it. Which outputs need careful review? Where are the chokepoints where mistakes compound? This is resource allocation, but the resource is judgment.
Developing engineers. If apprenticeship is the model, someone has to teach. The master provides feedback, explains reasoning, demonstrates judgment in real time. A master who doesn’t develop journeymen is failing at a core responsibility.
Intervening when it matters. Sometimes AI gets stuck. Sometimes the situation is novel enough that no prompting produces the right answer. The master maintains enough hands-on competence to recognize these moments and handle them directly. The authority to orchestrate comes from the ability to execute.
What’s missing at nearly every stage in the software engineer’s career path is the thing that currently defines it–actually writing code. A master engineer might write code occasionally—when demonstrating for an apprentice, when the problem is genuinely novel, or when something breaks at 2am. But code production isn’t the primary output. The primary output is context: the scaffold, the documentation, the decisions that make everything else possible.
This changes how we evaluate and compensate. You can no longer measure contribution by code output. For master engineers, the velocity of teams they work with, the quality of engineers they develop, and the disasters they prevent are key measures of productivity. These are harder to quantify than lines of code, but they’re what actually matters.
The Profession on the Other Side
In a future where one master engineer can do work that used to require a team of 5, less overall demand for engineers is inevitable. Those who remain are more productive, more valuable, and working on harder problems. A corner of the industry will continue to write code by hand for appropriate use cases for decades, just as there are still engineers writing assembly code.
The most likely outcome of software engineering as a field is a bimodal distribution. Practitioners moving through a defined progression—apprentice, journeyman, master—each stage with clear responsibilities and expectations on one side. A much larger population using AI tools for software-adjacent tasks who wouldn’t call themselves software engineers and wouldn’t be hired as such on the other. The middle, where most software engineering labor currently lives, largely empties out, either by skilling up, moving to adjacent roles, or changing industries entirely.
We will find ourselves left with a profession that looks much more like the established trades than it has at any other time. Formal apprenticeship, credentialing tied to demonstrated competence, and standardized practices will be the norm.
Despite the profound change in execution, the work is largely unchanged in nature. Software engineering remains a game of translation—bridging the gap between human intent and machine behavior. It is evolving from craft to trade, an inevitable and welcome sign of maturity. Engineers will become more devoted to business needs and making high value decisions. Free from the tyranny of code.
This transition is already well underway. Firms that recognize it are restructuring accordingly—flattening hierarchies, investing in context infrastructure, and building apprenticeship pipelines. Firms that don’t are still hiring to old ratios and wondering why their AI adoption isn’t delivering results.
Apprenticeship pipelines, like trees, take years to bear fruit. The masters you’ll need in five years have to start as apprentices today. The firms that started building two years ago are already ahead. The rest are quickly running out of time.
