The New Engineer: Shifting Skills in the AI Era
The Junior Developer Gap
Junior developers have traditionally been assigned small, well-defined tasks: fix this bug, add this field to the API response, write tests for this module, add this validation rule. These tasks are incremental, bounded, and safe — and they build the experience and system-level intuition that eventually produces Senior Architects.
AI is excellent at exactly these tasks. Boilerplate, small bug fixes, test generation, and CRUD endpoints are precisely what current AI tools handle most reliably.
The risk: if companies stop hiring junior developers because “AI can do those tasks,” the traditional training pipeline that produces Senior Architects breaks. The new junior skill becomes orchestrating AI — directing it to do 10× more work, critically reviewing its output, and maintaining quality across a larger scope — rather than writing individual lines of code.
Jevons Paradox
William Stanley Jevons observed in 1865 that making coal engines more efficient did not reduce coal consumption — it increased it, because cheaper, more efficient engines were deployed in far more places.
The same applies to software: making software 10× cheaper to build will not mean 1/10th the number of engineers are needed. It will mean companies demand 100× more software. The total amount of code the world needs is not fixed; it expands to absorb the available capacity to produce it.
The Shifting Skillset
Raw syntax knowledge is now a commodity. Knowing the exact parameter order of strpos() or the import path for numpy.linalg was valuable in 2010. In 2026, the AI knows that; you can ask and it will answer correctly in under a second.
What remains valuable:
| Skill | Why AI cannot yet replace it |
|---|---|
| Domain knowledge | Understanding the business, the users, the regulations, and the real-world constraints that the code operates within. AI only knows what was in its training data. |
| System design | Choosing architectures, trade-offs, and abstractions that will survive years of evolution. AI can generate a diagram; it cannot weigh the 5-year maintenance implications of a decision. |
| Human communication | Defining the right problem to solve. Eliciting actual needs from stakeholders who do not speak technically. Navigating organisational politics. AI cannot sit in a meeting room and read the room. |
| Critical judgement | Evaluating whether AI-generated code is correct, secure, and aligned with architectural goals — not just whether it compiles and passes tests. |
You are not “a React developer” or “a Python developer.” You are a problem solver who applies the best available tools — including AI — to the problem at hand. A technology stack’s lifespan is now 2–3 years; identifying with a specific stack is a career risk.
The Reasoning Ceiling
Current LLMs are excellent at:
- Pattern-matching against vast training data.
- Tasks with a clear, objective, automatable feedback loop (does it compile? do tests pass?).
They lack:
- Long-horizon strategic judgement across ambiguous, conflicting stakeholder priorities.
- Accountable ownership of consequences. If an AI makes a bad architectural decision that causes a production outage 18 months later, who is responsible? The AI cannot be; the engineer who approved the code is.
- Tacit, cross-domain organisational context — the knowledge a Senior Architect accumulates over years about their specific company’s systems, customers, and constraints. This context is not in any training dataset.
This is why an AI cannot currently replace a Senior Software Architect. It can accelerate their execution — generating 10 design options in the time it would take a human to sketch 2 — but it cannot exercise the judgement to choose among them.
What AI Changes (and What It Doesn’t)
AI changes the tools, not the goals. The core engineering questions remain:
- Is the code reliable — tested, robust under load, resilient to failure?
- Is it maintainable — can another human (or an AI) understand and modify it in 2 years?
- Is it secure — is user data protected, are dependencies audited, are attack surfaces minimised?
- Does it deliver real value — does it solve an actual human problem in a way that users will pay for or adopt?
AI will not replace software engineers. Engineers who use AI will replace engineers who do not.
Expected Learning
- Describe the Junior Developer Gap and explain how AI disrupts the traditional training pipeline.
- Explain Jevons Paradox as it applies to software development productivity.
- List the skills that remain difficult for AI and explain why each one matters.
- Define the Reasoning Ceiling and name at least two capabilities AI currently lacks.
- State the enduring engineering questions that AI does not change.
Past Paper Questions
Example Sheet 2, Question 10(b) contrasts a 2010 junior engineer’s experience with a 2026 junior engineer’s — testing whether you understand the skillset shift and the training-ladder problem. Question 10(c) asks about the Reasoning Ceiling. Question 11(c) tests whether you understand that Software Archaeology (recovering intent from git blame, issue trackers, and tribal knowledge) remains necessary because AI can summarise what code does but not why it was written that way.