Erik Caldwell
Connect on LinkedIn
Menu

The Topic Catalog · 5

Future Engineering Workforce & Organizational Design

Last updated · 7 min read

5.1 Which Engineering Skills Appreciate vs Commoditize in the AI Era

Priority: Must Understand

Executive Definition: Some engineering skills are becoming faster and cheaper to produce with AI assistance (boilerplate code, routine CRUD, first-draft tests, syntax-level fluency in a given language): these are commoditizing. Others are becoming more valuable precisely because AI can't reliably do them (system architecture judgment, knowing what to build and why, verifying and debugging AI-generated code, security review, and managing ambiguity): these appreciate. The risk for leadership is conflating "AI writes code faster" with "we need fewer senior judgment-holders," when the evidence points the opposite direction.

Why It Matters: DORA's 2025 report found AI adoption has a positive relationship with throughput but a negative relationship with delivery stability unless the organization has strong existing engineering practices: meaning code volume is up, but so is the burden of review, verification, and architectural coherence, which are exactly the skills that don't commoditize. GitHub's 2025 Octoverse data shows AI tools are actively reshaping which languages and patterns developers reach for, which is a leading indicator that lower-level implementation choices are increasingly delegated to tooling while higher-level system decisions remain human.

What I Need to Understand:

  • The DORA finding that trust in AI-generated code remains limited (roughly 30% of respondents report little or no trust in it) even as usage is nearly universal: a gap that puts a premium on review and verification skill, not a shortage of it
  • Why "prompt engineering" as a standalone skill is already commoditizing (tools abstract it) while "context engineering" (structuring what information a model has access to, curating retrieval, managing agent memory and tool access) is emerging as a genuinely durable skill
  • The distinction between a developer who ships AI-assisted code they can't explain and one who can explain, test, and defend it: only the second is doing work that appreciates
  • That security review, architecture, and incident response skill demand is rising, not falling, as more code (including AI-authored code) enters production faster
  • This is an active, contested area: there is no consensus taxonomy of "future-proof" skills, and confident lists of them should be read skeptically

Questions I Should Be Able to Ask My Team:

  1. Of the code merged last month that was AI-assisted, what fraction went through the same review rigor as hand-written code, and can you show me a case where review caught something real?
  2. Which of our senior engineers' skills would still be valuable if every line of new code were AI-generated tomorrow, and which of our juniors' skills would not be?
  3. Are we hiring and promoting for "can prompt a model well" or for "can architect a system and verify what a model produced": and does our leveling rubric actually distinguish these?

Technologies / Standards / Companies to Know: GitHub Octoverse (annual developer ecosystem data), DORA State of AI-assisted Software Development, context engineering (emerging term, not yet standardized) as distinct from prompt engineering.

Recommended Learning:

Time Investment: 1 hour

5.2 The Junior Engineer Pipeline Problem

Priority: Must Understand

Executive Definition: AI coding assistants disproportionately automate the kind of well-specified, low-ambiguity work that junior engineers traditionally learn on: meaning fewer organizations are hiring at entry level, which breaks the pipeline that has always produced tomorrow's senior engineers. This isn't a hypothetical: it's a measurable early labor-market pattern, though its size and permanence are still being established.

Why It Matters: Stanford's Digital Economy Lab found the employment gap for workers aged 22-25 in AI-exposed occupations widened from 15% (July 2025) to 19% (June 2026) relative to less-exposed peers, driven primarily by reduced hiring rather than layoffs of existing staff: a pattern with direct relevance to any large engineering organization deciding whether to keep funding junior hiring. If your organization quietly stops hiring juniors because AI makes senior-heavy teams look more efficient today, you are consuming a pipeline you didn't build and have no plan to replace in five to ten years.

What I Need to Understand:

  • The Stanford finding's own caveat: this is a documented correlation with a plausible mechanism, not proven causation: other factors (broader tech hiring slowdown, interest rates) are confounds the researchers themselves flag
  • The mechanism specifically: reduced hiring, not increased firing: meaning the damage shows up in your pipeline plans quietly, not in a headline layoff you'd notice
  • Why junior engineers historically learned architecture and judgment by doing the "boring" work AI now does, and what your organization's plan is to teach that judgment if the boring work disappears
  • That this is a multi-year strategic risk (who becomes your senior engineers in 2032?) that a large enterprise engineering organization has more control over than commentary suggests: you can choose to keep hiring and training juniors even if the market average doesn't
  • This remains an actively studied, evolving area: treat specific percentage figures as a snapshot, not a settled long-run trend

Questions I Should Be Able to Ask My Team:

  1. How many junior/entry-level engineers have we hired in the last four quarters compared to two years ago, and was that a deliberate decision or a side effect of AI-driven "efficiency" targets?
  2. If we stopped hiring juniors for three years, what would our senior engineering bench look like in 2031, and who has modeled that?
  3. What is our actual plan for how a junior engineer develops architectural judgment when AI does the tasks they used to learn from?

Technologies / Standards / Companies to Know: Stanford Digital Economy Lab (Canaries dashboard: ongoing tracking, not a one-time study), IEEE Spectrum workforce reporting.

Recommended Learning:

Time Investment: 1 hour

5.3 Changing Roles, Team Topology & Hiring/Competency Frameworks for the AI Era

Priority: Should Understand

Executive Definition: As AI agents take on more implementation work, the shape of engineering teams and the definition of roles like staff engineer and engineering manager are shifting: staff engineers increasingly spend time directing and reviewing agent output rather than only writing code themselves, and managers are starting to think about "how many agents can one engineer effectively supervise" the way they once thought about span of control over people. None of this has settled into an industry-standard org chart or competency framework yet: it is actively being worked out in public by practitioners.

Why It Matters: Getting team topology wrong here has a direct cost: DORA's 2025 report identifies seven distinct team archetypes ranging from "foundational challenges" (low performance, high burnout) to "harmonious high achievers," and which archetype a team falls into is strongly related to whether roles and workflows were deliberately redesigned for AI-assisted work or simply had AI tools bolted onto an unchanged structure. Your hiring rubrics and leveling guides (written for a world where seniority mostly meant "writes more/better code") need updating for a world where reviewing, directing, and verifying AI output is itself a core skill being evaluated.

What I Need to Understand:

  • There is no settled "engineer-to-agent ratio": any specific number offered as a benchmark right now is speculative, not empirical, and should be treated that way in this document and in vendor pitches
  • Team Topologies' existing vocabulary (stream-aligned, platform, enabling, complicated-subsystem teams) is being actively extended by its own authors to describe agent-inclusive teams: this is the most credible existing framework to anchor on, not a from-scratch invention
  • How staff engineer and EM job descriptions are changing in practice: more time on review/verification/architecture, less time on raw output, and whether your leveling criteria and interview loops have caught up
  • The risk of over-rotating: treating "can direct AI agents" as a proxy for seniority without also verifying the underlying engineering judgment that makes that direction sound
  • This is one of the least mature topics in this document: flag any confident claim about "the right ratio" or "the new org chart" as an opinion, not a finding

Questions I Should Be Able to Ask My Team:

  1. Have we actually updated our staff engineer and EM leveling criteria and interview loops for AI-assisted work, or are we evaluating people against a pre-AI rubric while expecting AI-era output?
  2. When an engineer directs multiple AI agents at once, who is accountable when something goes wrong in production, and does our incident process reflect that?
  3. Where did we get any "agents per engineer" ratio we're using for planning, and would we accept that level of evidence for any other headcount decision?

Technologies / Standards / Companies to Know: Team Topologies (Matthew Skelton & Manuel Pais: the org design framework being actively extended for AI), DORA team archetypes, GitHub/Anthropic/OpenAI internal engineering blogs (useful as case studies, not standards).

Recommended Learning:

Time Investment: 1 hour