Generative AI Is Not Going To Build Your Engineering Team For You

Charity Majors · article · 2024-06-10 source ↗ Reader 🖥️

Durable, Domain-Owning Teams (vs. Fluid Teams)Junior Hiring Economics Small Teams & Compression Sociotechnical Architecture Systemic Apprenticeship & Skill Transmission Talent Density

Generative AI accelerates the easy, narrow, disposable part of software engineering (writing code) but does nothing for the hard part (building and operating the sociotechnical systems code lives in), so it cannot substitute for hiring and apprenticing junior engineers — teams, not individuals, are the real unit of software ownership, and starving the junior pipeline is cannibalizing the industry's own future senior engineers.

practical · argumentative — Argues against a specific prevailing claim (generative AI is making junior engineers unnecessary) toward a specific recommended action (keep hiring and training junior engineers, deliberately and continuously).

Structure

Part	Role
Author's own career origin story (dropped out at 19, learned on the job)	narrative/credibility — establishes the now-vanished low-barrier entry ladder and personal stakes
The software industry is growing up / apprenticeship industry / what 'senior' means	foundation — defines seniority as systems judgment built over years, not coding output
Writing code is the easy part; code is easy, systems are hard	core claim — locates AI's actual contribution (code generation) outside the hard, bottleneck work
The 'excitable junior engineer' analogy, interrogated and limited	counter-argument to the 'AI replaces junior engineers' claim
Teams as the unit of productivity; cost asymmetry between senior and junior hires	economic/organizational argument
The bottleneck is hiring, not training; long-term vs. short-term arguments for hiring juniors	diagnosis + call to action
Even if AI could fully automate development, senior human judgment would still be needed for auditability	forward-looking hedge/conclusion

Key terms

Senior engineer
Not a function of coding output or speed, but of the ability to understand, maintain, explain, and manage a large body of software in production over time, translate business needs into implementation, and teach — built through roughly seven-plus years of daily practice on a team alongside more experienced engineers.
Sociotechnical systems
Software, tools, and people together — understanding a system requires familiarity with the interplay between code, users, production, infrastructure, and continuous change over time; these systems are complex, chaotic, nondeterministic, and subject to emergent behavior.
Apprenticeship industry
A characterization of software engineering: you cannot learn the job from books or a CS degree alone; competence is built almost entirely through sustained, supervised, on-the-job practice over years.
Barrels vs. ammunition (implicit contrast, not named in this piece)
n/a — not the author's term; included here only as a cross-reference point. Majors' own frame is 'team as the unit of productivity,' explicitly rejecting the idea that an individual's seniority alone determines their value to a team.

Propositions

explicitcontestedBeing a senior engineer is primarily about judgment, systems understanding, and the ability to teach — not coding speed or output — and this capability takes roughly seven-plus years of daily writing, reviewing, and deploying code on a team alongside more experienced engineers to develop; it cannot be learned from books or accelerated past a floor set by practice.conf: high
contradictsStop being skeptical about AI for development with Charity Majors · p6 — Same author, ~2 years apart: here (2024) Majors argues AI-generated code 'cannot be trusted' and must be read line-by-line before committing; by 2026 she argues it's 'when, not if' engineers ship AI-written code to production that they've never read and don't understand — an explicit, self-acknowledged reversal of her own position as the harness/validation layer matured, worth tracking as her view evolving rather than a one-off inconsistency.
explicitdevelopedWriting code is the easiest part of software engineering and is getting easier by the day; the hard, durable parts are operating, understanding, extending, and governing code over its entire lifecycle inside complex, nondeterministic, emergent sociotechnical systems.conf: high
extends ←Disposable Code Is Here to Stay, but Durable Code Is What Runs the World · p2 — Same author (Charity Majors), ~14 months later, sharpens her own earlier claim that 'writing code is the easiest part' into a named two-domain framework (disposable vs. durable) organized explicitly around maintenance cost.
explicitestablishedGenerated code cannot be trusted and must be read and revised line by line before committing; the more important or meaningful a piece of code is, the less likely AI generation produces a directly usable artifact — so generative AI's real strength is tightly-scoped, predictable, low-stakes, tedious code, not the work that matters most.conf: high
supports ←Disposable Code Is Here to Stay, but Durable Code Is What Runs the World · p5 — Both argue AI-generated code cannot be trusted on the basis of test coverage or review alone; trust/confidence has to be earned through time and exposure (production track record), consistent with the earlier article's 'read and revise line by line' stance.
supports ←How to measure AI developer productivity in 2025 | Nicole Forsgren · p6 — Both describe the same shift -- code review/verification time displacing writing time -- as the real cost center of AI-assisted development, requiring active evaluation of AI output rather than acceptance on faith.
explicitcorroboratedThe 'generative AI is like an excitable junior engineer' analogy only holds for disposable, self-contained code never meant to be integrated into a larger body of work or maintained by others — which is a narrow and atypical case; for ordinary production code the analogy fails because AI provides no feedback loop, no apprenticeship relationship, and no contribution to team culture.conf: high
supports ←Redefining the Software Engineering Profession for AI · p3 — Both use a concrete failure case to argue that AI output requires a reviewer who already has systems judgment -- the thing EiC developers specifically lack -- making the 'AI as excitable junior' analogy misleading for real production code.
refines ←Disposable Code Is Here to Stay, but Durable Code Is What Runs the World · p8 — Both make the same point -- that the 'AI is like a junior engineer' framing only fits disposable, throwaway code -- but this article gives that case a name and a cost-model justification ('disposable code') rather than treating it as a narrow exception.
explicit⚡ disputed & corroboratedThe smallest unit of software ownership is the team, not the individual, because only a team can own, build, and maintain a corpus of software over time — so hiring decisions should optimize team composition and diversity of skill levels, not any single hire's individual output.conf: high
contradictsHard truths about building in the AI era | Keith Rabois (Khosla Ventures) · p1 — Majors argues the team, not the individual, is the unit of productivity and that a range of skill levels (including juniors) is what makes a team healthy; Rabois' 'barrels, not ammunition' framing argues output capacity is determined by concentrating individually-exceptional people, which is close to the opposite organizing principle for how to build a team.
supports ←How AI will change software engineering · p4 — Same claim (team, not individual, is the unit of software ownership/productivity) from the same source (Charity Majors), in near-identical language, in a different article.
explicitdevelopedA team composed entirely of one skill level (all senior/staff/principal, or all intermediate, or all junior) is dysfunctional: an all-senior team produces contention over scarce high-level work, encourages over-engineering and corner-cutting, and chronically under-documents — problems that a team with a genuine range of levels, matched to a genuine range of task complexity, avoids.conf: high
extendsPresentation: A Few Predicted Talks From QConAI 2030 · p1 — Where that talk describes the senior engineer's role shifting toward orchestrating/conducting multiple agents, Majors' account of why single-level teams are dysfunctional implies the same logic should apply to agent orchestration: a team (human or human+agent) that is uniformly 'senior-conductor' work, with no range of levels, would plausibly show the same contention and under-documentation pathologies she describes for all-staff human teams.
extends ←How AI will change software engineering · p4 — This article's 'cheapest senior hires' framing is the specific failure mode the fuller Majors essay generalizes into 'an all-senior team is dysfunctional'.
explicitcorroboratedOrganizations systematically overestimate the ongoing cost of hiring a junior engineer (treating it as a near-permanent productivity tax) and underestimate the ramp cost of hiring a senior engineer (6-9 months to build system familiarity, ~1 year to full speed) — juniors become net-positive on a comparable timescale and may contribute value beyond the code they personally write.conf: high
extends ←The Bet On Juniors Just Got Better · p5 — Majors argues organizations overestimate junior cost and underestimate senior ramp cost, concluding juniors become net-positive on a comparable timescale; Beck supplies the quantified mechanism (augmented-coding ramp compression and its effect on breakeven-survival odds) for why that calculus has shifted further in juniors' favor.
supports ←Redefining the Software Engineering Profession for AI · p5 — Both argue organizations should accept the short-term capacity cost of hiring early-career engineers as an investment rather than a pure productivity tax.
explicitestablishedThe actual bottleneck constraining the supply of future senior engineers is not training junior engineers once hired — it's getting them hired at all, because companies treat entry-level hiring as an externalizable cost rather than an investment in their own future talent supply.conf: high
supports ←Redefining the Software Engineering Profession for AI · p2 — Both identify the bottleneck as organizations not hiring EiC/junior engineers in the first place (an externalized cost), not a training-once-hired problem.
supports ←How AI will change software engineering · p5 — Both identify the real bottleneck as firms declining to hire/train juniors at all (an externalized cost), not a training-capacity problem once hired.
explicitEven in a hypothetical future where AI could fully automate software development, the inability of humans to audit or debug AI's decisions would make running a business on such a system an unacceptable existential risk to any legal, security, or finance function — so demand for human engineering judgment persists independent of raw code-generation capability.conf: medium
explicitFixing the junior-hiring pipeline is a professional-advocacy problem that engineers and engineering managers must personally fight for inside their own organizations, because finance and executives are structurally disinclined to internalize a cost whose payoff is long-term and industry-wide rather than immediate and firm-specific, and only engineers have the context and credibility to make the case.conf: high
explicitNot every company should hire junior engineers — only those with sufficient runway, slack (not constant firefighting), experienced managers, a product roadmap, and at least one person willing to mentor — because a bad first experience is worse than none for both the junior engineer and the broader case for junior hiring.conf: high

Arguments

Generative AI will not reduce the need to hire and train junior engineers, and treating it as a substitute is a mistake with long-term costs to the industry. strength: high

Explicit premises:

Writing code — the part AI accelerates — is the easy, non-bottleneck part of software engineering.
The hard, scarce capability (understanding and operating complex sociotechnical systems) is built only through years of supervised on-the-job apprenticeship, which requires there to be junior engineers in the pipeline in the first place.
Teams, not individuals, are the unit of software ownership, and functional teams require a genuine range of skill levels including juniors.
The true cost comparison between hiring a senior and hiring a junior is closer than commonly assumed once ramp time is properly accounted for on both sides.

Implicit premises:

Current junior engineers are the pool from which future senior engineers are drawn; there is no other viable supply mechanism for senior-level judgment.
The industry-wide, collective-action problem (every firm wants someone else to train juniors) will not resolve itself without explicit advocacy, because market incentives alone externalize the training cost.

Inferences:

If the premises hold, an organization that stops hiring juniors now because AI appears to substitute for their output is making a bet against its own future senior-engineer supply — a bet whose cost will only become visible 5-7+ years later, well past the tenure of the executives making the decision.

Narratives

The author's own origin story: homeschooled in rural Idaho, no computer until 16, a series of non-technical majors, who nonetheless entered the software industry as a complete novice and learned everything on the job during an era of low hiring standards and plentiful jobs — contrasted with her sister's two-year struggle to land a first engineering job 'a few years ago.'
→ Establishes both personal authority and the concrete, felt stakes of the 'bottleneck is hiring' argument — it supports the proposition that the industry's entry ladder has already narrowed sharply, independent of AI, and that AI-driven junior-hiring freezes would make an already-hard problem worse.
Kent Quirk's description of generative AI as 'an excitable junior engineer who types really fast.'
→ Supplies the central analogy the middle of the piece builds up and then dismantles — the narrative device lets the author concede AI's genuine resemblance to a junior engineer in one narrow respect (untrustworthy output) before showing the analogy breaks down everywhere else (no feedback loop, no apprenticeship, no team-culture contribution).
A vignette of a team staffed entirely with staff/principal engineers: competing for the 'fun' architecture work, picking technical fights, chronically under-documenting.
→ Concretely supports the proposition that single-level teams are dysfunctional, by showing the specific behavioral pathology (contention, over-engineering, under-documentation) rather than just asserting it abstractly.

Questions addressed

✅ Will generative AI make it unnecessary to hire and train junior software engineers?
No — AI accelerates code-writing, which is the easy, non-bottleneck part of the job; the apprenticeship pipeline that produces senior judgment still requires junior hires.
✅ What actually makes an engineer 'senior,' if not the ability to write code quickly?
Judgment, systems understanding built over ~7+ years of practice, and the ability to teach — not output.
✅ Should every company hire junior engineers?
No — only companies with runway, slack, experienced management, a roadmap, and a willing mentor should; a bad junior-hiring experience is worse than none.
⭕ If AI is especially good at exactly the tedious, repetitive, tightly-scoped code that intermediate and junior engineers traditionally cut their teeth on (web forms, login pages, boilerplate), where do new engineers get the volume of practice reps the author's own apprenticeship model says they need?
Not addressed. The piece praises intermediate engineers for writing 'reams and reams' of exactly the kind of code it elsewhere identifies as AI's sweet spot, without reconciling the two claims.

Gaps

illogicalThe piece simultaneously argues (a) that generative AI is especially good at tedious, predictable, tightly-scoped code, and (b) that junior and intermediate engineers develop their skill precisely by writing large volumes of that same kind of code ('reams and reams,' web forms, login pages 'for the 1000th time'). If AI increasingly absorbs exactly those reps, the piece's own apprenticeship timeline (seven-plus years of daily practice) is put under pressure that the piece never acknowledges or addresses.
Read next: Look for later work (including the author's own 2026 piece on AI skepticism, extract-charity-majors-stop-being-skeptical-ai-development) that revisits whether AI-written code changes what apprenticeship requires, or whether the practice-reps juniors need shift from writing code to reviewing/debugging/understanding it.
closed byThe Bet On Juniors Just Got Better — Majors' piece leaves unresolved how juniors can still develop skill through 'reams and reams' of tedious code if AI increasingly absorbs exactly that work. Beck's augmented-coding model answers this directly: AI collapses the mechanical search/exploration part of a task (which API to use, syntax lookups) rather than the judgment part, and the time saved is reinvested in deliberate reflection (tradeoffs, alternative approaches, tests, performance) -- so the practice-reps shift from writing boilerplate to evaluating and extending AI-surfaced options, rather than disappearing, provided management deliberately manages for that outcome.
incompleteThe 'first job is murder' bottleneck is framed almost entirely through a US, Big-Tech-adjacent lens (top colleges, feeder systems, connections) without addressing how the dynamic plays out in different labor markets, education systems, or company sizes outside that frame — e.g. apprenticeship or vocational-training traditions in other countries that structure entry-level hiring differently.
Read next: Look for comparative accounts of entry-level engineering hiring outside the US Big-Tech pipeline, or vocational/apprenticeship-model traditions (e.g. German Ausbildung, or Norwegian fagbrev-style models) applied to software.

Closes gaps elsewhere

Hard truths about building in the AI era | Keith Rabois (Khosla Ventures) · g3 — Majors directly addresses 'how to develop barrels': systemic, continuous junior hiring plus deliberate team composition across skill levels, not innate selection — the mechanism the barrels framework leaves unexamined.
Hard truths about building in the AI era | Keith Rabois (Khosla Ventures) · g4 — Against the 'barrels are born, not made' framing, Majors gives an explicit developmental account: senior judgment ('barrel' capability) is built through a ~7-year apprenticeship of supervised practice, mentored by someone one level ahead — a concrete claim about how the capability is produced, not an assertion that it's innate.