The Will to Code

Lead Summary

Software engineering is one of the few occupations where workers simultaneously claim the status of artists, engineers, scientists, and craftspeople — and where no one can agree which claim is correct. The title "software engineer" is legally unprotected in most of the world; the profession's institutional bodies split over licensing in 1999 and never fully reconciled; and entry is possible without formal credentials at all. Yet the people who write code have, over seven decades, built a remarkably coherent occupational identity: creative, meritocratic, technically sovereign, and defined above all by the act of making.

That identity is now under pressure from generative AI coding tools. These tools do not merely augment engineers — they perform the foundational tasks through which engineers historically became engineers. The cognitive offloading, tacit knowledge transmission, and craft-through-struggle that made the profession feel like a vocation are being disrupted, with uneven consequences across career stages, geographies, and cultural contexts. What is emerging is not a clean replacement of human coders by machines, but something more complicated: a fracture in the shared story engineers tell about themselves.

Historical Development

The Making of the Programmer Archetype

Programming identity has never been neutral. Its earliest contours were shaped by hiring practices in the 1950s and 1960s that transformed an occupation once populated by women (early computing operators and human "computers") into one dominated by men. By the mid-1960s, 80% of companies used aptitude tests and personality profiles to screen programmers. These tests claimed gender neutrality, but they systematically privileged formal mathematics training, disinterest in interpersonal interaction, and traits associated with elite male education — acknowledged even at the time as poor predictors of actual performance, yet maintained because they were cheap and convenient. The tests did not so much discover the "natural" programmer as construct one: male, antisocial, mathematically exceptional.

By the end of the 1960s, the "Real Programmer" archetype had crystallized into recognizable masculine stereotypes: the bearded "programming guru," the youthful "whiz kid," the "computer cowboy." The 1970s and 1980s added the "computer bum" — an obsessive, antisocial figure monopolizing machines at night — later sensationalized as the "hacker." By the 1980s, the "computer nerd" had become normalized in popular culture as eccentric, unkempt, unequivocally male. Silicon Valley amplified this through founder mythology: the lone-genius dropout whose vision, not training, built the future. These stories elided the collective, publicly-funded foundations of technological innovation and naturalized the concentration of technical authority in white male elites as mere "merit."

The Craft Turn

Against this background of masculine mystique, a different story was also being told — one that positioned programming as learned craft rather than innate genius.

Donald Knuth's 1974 Turing Award lecture, "Computer Programming as an Art," made the case explicitly. Knuth argued that programming was "something devised by man's intellect" and drew explicit comparisons to poetry and music: "when we prepare a program, it can be like composing poetry or music." This framing — programming as aesthetic, expressive practice — became foundational to how the computing community understood its work.

Richard Sennett's The Craftsman (2008) took this further, arguing that Linux development exemplified modern craftsmanship: quality-oriented practice rooted in human commitment to excellence, available to anyone willing to participate. Sennett positioned open-source communities as embodying craft values — skill development through practice, artifacts available for others to learn from, quality for its own sake.

The Software Craftsmanship movement formalised these intuitions as professional ideology. Originating with Jack W. Reeves (1992) and crystallizing through The Pragmatic Programmer (1999) subtitle "From Journeyman to Master," and later the Software Craftsmanship Manifesto, the movement drew explicit parallels to medieval guild traditions: apprenticeship, mastery, care. Robert C. Martin's Clean Code (2008) reframed programming identity around craft values — commitment to quality, code written not just for machines but for the other programmers who will read it. The Agile movement itself emerged from programmers holding these craft values as central. Programming was thereby positioned as a creative, learnable discipline with ethical and aesthetic dimensions.

Code readability and quality are evaluated through the lens of communicating to other human programmers, not merely satisfying compiler requirements — placing the programmer in a role that requires consideration of audience, clarity, and aesthetic coherence, much like literary writing.

The Contested Profession

What makes software engineering distinctive as a profession is that it never fully professionalized. The ACM and IEEE split in 1999 over whether to require formal licensing. IEEE supported making software engineering a licensed profession; ACM objected, arguing the knowledge base was too immature and that licensing would give false assurances while excluding valuable practitioners. The result: software engineering remains partially professionalized in some jurisdictions (Texas, Australia, Canada) but the title is unprotected in most of the world. Anyone may call themselves a "software engineer" without certification or licensure.

This unresolved status has profound consequences. Without occupational closure — the mechanism through which professions like medicine and law control who may practice — software engineering cannot defend its jurisdictional claims through formal gatekeeping. Community norms, informal reputation systems, craft ideology, and labor market dynamics fill the vacuum. Identity becomes doubly important precisely because formal credentials cannot do the work.

Core Concepts

Professional Identity and Competence, Autonomy, Relatedness

Contemporary research identifies three dimensions along which engineers experience professional identity: competence (belief in one's technical capability), autonomy (agency over craft decisions), and relatedness (social connection through shared practice and mutual recognition). These are not merely psychological abstractions — they describe the specific texture of what it means to be an engineer as lived experience.

Historically, all three were satisfied through the act of writing code: you developed competence by solving problems, you exercised autonomy in your design choices, and you bonded with colleagues through code review, pair programming, and shared technical culture. The craft act was simultaneously the identity act.

The Deskilling Tension

Labor process theory, originating from Marx's analyses of industrialization and formalized by scholars like Henry Braverman, describes how capitalist production transforms skilled craft work into routinized, simplified tasks controllable by management. Deskilling historically involved separating conceptual design from execution, reducing tasks to simple routines, and replacing skilled craftspeople with cheaper less-skilled labor.

This framework has applied to software engineering since at least the 1970s. STS scholarship identified structured programming, modularization, and hierarchical team organization as mechanisms explicitly designed to routinize and reduce programmer skill requirements. The tension between craft ideology (professional autonomy) and labor process theory (deskilling toward management control) has never been resolved; it simply resurfaces each time new technology enables new forms of task fragmentation.

Jurisdictional Claims and AI

When AI systems can perform tasks previously reserved to credentialed professionals, the profession's claim to jurisdictional control — its assertion of exclusive expertise and right to control a domain — is undermined. As research frames it, "AI identity threat is distinctive because AI acts as a quasi-social agent, blurs human-machine role boundaries, and operates as inscrutable black boxes." The identity crisis that engineers face when confronted with AI capability is not merely anxiety about unemployment; it is a challenge to the social legitimacy of the profession's claim to expertise.

The AI Disruption: What the Research Shows

The Productivity Paradox

The headline findings about AI coding tools are contradictory at first glance, but they cohere into a pattern.

Self-reports are positive: 84% of developers adopted AI coding tools by 2025, 52% report perceived productivity boosts, and 60-75% of GitHub Copilot users report feeling more fulfilled and less frustrated. Controlled experiments tell a different story. METR's 2025 study with experienced open-source maintainers found that developers using AI tools were objectively 19% slower on actual tasks, while self-reporting approximately 20% faster. This 39-point perception-performance gap represents a fundamental failure of calibration — developers experience the activity of AI-assisted coding (instant suggestions, rapid iteration loops) as productive, even when aggregate task completion time increases.

Specific task categories show genuine gains: 30-60% time savings on tests, documentation, and refactoring represent real use case benefits. But code generation — the highest-profile AI capability — is where the trouble concentrates. PR review time increased approximately 91% in teams with high AI adoption; PR size grew 154%; code churn rates doubled from 3.1% in 2020 to 5.7% in 2024. AI-co-authored pull requests contain 1.7x more issues than human-authored PRs, with correctness problems at 1.75x higher rate, maintainability issues at 1.64x, and security vulnerabilities at 1.57x.

Additionally, approximately 48% of AI-generated code contains potential security vulnerabilities, substantially higher than human-only code baselines. The context problem compounds this: 65% of developers report missing context during refactoring, and approximately 60% during test generation and code review. AI tools cannot access team conventions, architectural decisions, and organizational constraints — the situated knowledge that defines professional competence.

The Cognitive Offloading Problem

The deeper concern is not what AI does to code quality today but what it does to engineer capability over time. Cognitive offloading — the systematic externalization of higher-order cognitive processes to automated systems — is the mechanism of concern.

Empirical evidence is accumulating. Junior developers using AI for code generation scored 17% lower on comprehension tests when learning new libraries compared to unassisted peers. Developers delegating code generation to AI scored below 40% on debugging and conceptual understanding tests; those using AI strategically for conceptual inquiry (not code delegation) scored 65% or higher. An Anthropic randomized controlled experiment found that AI use impairs debugging abilities without delivering significant efficiency gains on average.

The problem is self-reinforcing. Tacit knowledge in software engineering — the hard-to-codify practical expertise developed through hands-on problem-solving — forms primarily through repeated struggle with unassisted tasks and observation of more experienced practitioners. When learning is mediated entirely by AI tools, developers bypass the cognitive struggle required to internalize heuristics, interpretive patterns, and intuitive judgment. Research shows that entry-level automation can reduce the growth and welfare of organizations by reallocating novices away from the most productive experts, weakening the intergenerational transmission of best practices.

Critically, not all AI use produces equivalent outcomes. Research identifying six distinct AI interaction patterns found that three — involving active cognitive engagement (hypothesis formation, critical evaluation, deliberate practice) — preserve learning outcomes even with AI assistance. Three patterns — outsourcing decision-making, reducing hypothesis formation, treating AI as an answer provider — produce learning deficits and skill atrophy. The pedagogical and cognitive design of tool interaction is the determining factor, not AI use per se.

Identity Under Pressure

The Competence, Autonomy, and Relatedness Threats

Research on junior engineers shows measurable professional identity threat from generative AI adoption, specifically threatened in their need for competence — while senior engineers report significantly lower competence threat. This differential reflects structural vulnerability: junior engineers' skill-building pathways have been rendered redundant by AI code generation.

Beyond competence, engineers experience threat to autonomy and relatedness. The shift from engineers authoring code to engineers directing AI to generate code represents a meaningful erosion of autonomous decision-making in core craft activity. It also threatens the social bonding that historically structured professional identity — code review as mutual recognition, pair programming as shared practice, mentorship as intergenerational craft transmission. When AI absorbs these interactions, the relational infrastructure of engineering identity is disrupted.

Engineers respond through active identity protection: reframing AI as tool rather than replacement, emphasizing unique value in high-level problem-solving, reconceptualizing competence domains. These are coping strategies rather than passive acceptance, and their prevalence signals genuine threat to occupational identity.

The Social Evaluation Penalty

An underappreciated dimension of the AI disruption is social. A PNAS study (2025) involving over 4,400 participants demonstrated that AI tool users are consistently rated as lazier, less competent, and less diligent than peers who received equivalent help from human colleagues. This penalty is pervasive across age, gender, and occupational categories.

The mechanism is the effort heuristic: people rely on visible struggle, time investment, and evidenced dedication as proxies for superior quality. Tool-assisted work, by reducing visible struggle, triggers attributions of low motivation that cascade into overall competence judgments — independent of actual output quality.

The penalty has real-world consequences. Managers who do not use AI themselves are significantly less likely to hire candidates who regularly use AI tools. However, the penalty is moderated by context: when AI use makes contextual sense for a specific task, and when users are transparent about tool use in ways that frame it as enhancing rather than replacing unique skills, the penalty substantially decreases. The penalty also appears temporally contingent on adoption phase — as tool use becomes normative, norm deviation (the mechanism producing the penalty) diminishes.

Labor Market Restructuring

The Junior Collapse

Entry-level software engineering employment has contracted measurably. Employment for software developers aged 22-25 declined nearly 20% from late 2022 peak by July 2025. Entry-level job postings dropped 60% between 2022-2024. Leading tech companies hire approximately 50% fewer new graduates compared to 2021. The Stanford Digital Economy Lab's research found a 16% relative decline in employment for early-career workers in high-AI-exposure occupations like software engineering, compared with stable employment in low-exposure occupations.

The structural cause is task substitution. AI tools directly absorbed work historically assigned to junior engineers for skill-building: boilerplate generation, basic bug fixes, simple CRUD applications, documentation automation. 70% of hiring managers surveyed believe AI can perform intern tasks; 57% trust AI output more than junior or recent graduate contributions. The economics of internship programs have broken down: when AI performs the same work, the cost-benefit of hiring interns diminishes.

The Senior Bifurcation

The labor market is bifurcating. More than half of current US software engineering job openings target senior or staff-level candidates. Senior and staff roles are growing while junior roles contract. The skills that AI cannot easily replace — communication, domain knowledge, system fundamentals, architectural thinking — are precisely what defines senior-level work.

What is emerging looks like a two-track system: commodified junior work (increasingly automated and contracted) versus premium senior work (expanded scope, higher value). The practical problem is that the pathway from junior to senior passes through the junior work that is disappearing. How engineers in the future will acquire the tacit knowledge and situated judgment that currently requires years of "doing the work" is an open question.

The Orchestrator Turn

From Coder to Conductor

The engineering role is shifting from direct code production toward orchestration, coordination, and validation across AI agents and automated systems. Rather than writing code line-by-line, engineers increasingly define objectives, decompose complex tasks into workflows, coordinate parallel AI agents, and validate outputs — roles analogous to a conductor coordinating an orchestra.

This shift requires fundamentally new competencies: prompt engineering, AI-human workflow design, quality orchestration across parallel agents, and context-aware decision-making about task decomposition and agent allocation. Multi-agent architectures — where specialized AI agents work in parallel on decomposed task components — are becoming practical, with engineers experimenting with running 3-4 agents simultaneously on separate features.

New organizational roles are emerging: Quality Orchestrators who manage systematic validation of AI-generated work across multiple dimensions (security, logic correctness, performance, maintainability, architectural fit); AI-human workflow specialists; and hybrid development pod leaders. These roles require understanding multi-agent systems, cognitive load management in human-AI collaboration, and design-before-execution thinking.

A Choice, Not an Inevitability

Deskilling is not an inevitable consequence of AI integration — it is a choice about organizational deployment. Research distinguishes two paths: labor-replacement models (trim teams, ask remaining engineers to manage automation) and hybrid intelligence models (AI handles routine work, freeing humans to focus on architecture, integrations, and creative design). This choice fundamentally shapes whether the "orchestrator" role means supervising automated execution or designing high-level system objectives — the difference between an elevated and a diminished form of professional identity.

Code review becomes the critical path bottleneck in this transition. As AI accelerates code generation, manual human review becomes disproportionately expensive. PR review time increased approximately 91% in teams with extensive AI use. The orchestrator must therefore design validation systems that combine automated checks, specialized human review, and AI-assisted analysis — a qualitative shift from "code author responsible for code quality" to "orchestrator responsible for validation process design."

Class Consciousness and Collective Response

The professional identity disruption is also generating collective political responses, though these are complicated by tech work's distinctive class position.

Tech workers in China have adopted self-identification terms — dagongren ("worker"), manong ("coding peasant"), shechu ("company livestock") — that explicitly frame themselves as members of the working class. The 2019 996-schedule campaign, where Chinese tech workers protested 9 AM to 9 PM, 6-day work schedules, generated nationwide conversation about white-collar worker precarity and class consciousness among programmers.

In the US, organized tech labor has accelerated since 2020. The Communications Workers of America, OPEIU, and Teamsters have launched coordinated industry campaigns. Union formations have occurred at Alphabet, Glitch, Kickstarter, Medium, the New York Times, and Washington Post. The Alphabet Workers Union pioneered "pre-majority unionism" — securing concrete workplace gains (severance, benefits, worker representation) without formal majority recognition across entire workforces, adapted to the tech industry's legal and cultural resistance to traditional unionization.

Yet tech workers face structural obstacles rooted in professional culture. Organizers document that tech workers "over-index" on technical problem-solving while neglecting the relational work core to labor organizing. More fundamentally, tech workers occupy a contradictory class position — oscillating between a spirit of emancipation and entrepreneurial capitalism — that complicates collective identification as workers. The "builder" reframing represents an ideological response to material conditions of deskilling and precarity: rather than reconceptualizing oneself as a worker, one reframes as an entrepreneur maintaining autonomy. This individualist response to collective conditions is historically characteristic of craft workers under deskilling pressure.

Controversies and Debates

Does AI democratize or concentrate coding access? AI tools lower technical barriers to entry, enable developers in emerging economies to build skills rapidly, and make non-degree technical roles more accessible. Yet this democratization of access coexists with credential-based gatekeeping persistence, and paradoxically raises competence standards for sustainable employment. The entry-level employment contraction occurred simultaneously with the democratization narrative, suggesting they describe different populations and different timescales.

Is the productivity slowdown real? The METR study showing 19% slowdown used experienced developers on real production codebases. Critics note that the tasks were harder than typical AI use cases and that tools have improved since early 2025. The task-specific gains (30-60% on documentation, testing, refactoring) are also real. The honest answer is that effects are highly task-dependent, user-expertise-dependent, and organizational-context-dependent — which itself challenges simple productivity narratives in either direction.

Is deskilling inevitable? STS scholarship documented earlier milestones (structured programming, modularization) as designed to routinize programmer work, yet the profession maintained craft identity through those transitions. What makes the current moment different, potentially, is the scale and speed of capability change — and the specific disruption of the junior-to-senior learning pipeline, which previous automation did not touch in the same way.

Current Status

The professional identity of software engineers is in active reconstruction. The craft ideology that sustained the profession through previous technological transitions — structured programming, object-oriented design, the web, mobile — is being tested by tools that perform the craft act itself. The outcome is genuinely undetermined: whether AI integration leads to elevated orchestrators exercising higher-order creative and architectural judgment, or to degraded "code adjusters" in deskilled labor processes, depends substantially on organizational choices, educational responses, and collective professional action.

What is already visible is structural: the junior hiring pipeline is contracting, tacit knowledge transmission is being disrupted, the social evaluation of AI tool use is in flux, and the labor market is bifurcating toward a senior premium that cannot be reached without the junior pathway that is disappearing. These are not individual psychological adjustments but systemic changes to how the profession reproduces itself.