Nobody Pays Programmers for Code

Most discussion about computer programming jobs starts too low in the stack. It starts with languages, frameworks, and salary bands. That misses the point. Programming labour is priced by proximity to revenue, control, and liability.

AI makes that clearer. The best-known productivity result in this area is not "pull requests merged 55% faster". It is the controlled GitHub Copilot experiment by Peng et al.: developers using Copilot completed one bounded JavaScript task 55.8% faster than the control group in a study of 95 professional developers. That was a lab-style task, not production telemetry, and it did not show that strategic depth or code quality rises at the same rate (arXiv; GitHub research summary). That is the signal that matters. Routine implementation gets faster. Judgement does not automatically compound with it.

So I do not see computer programming jobs as a clean ladder from junior to senior. I see a labour market being renegotiated around who defines systems, who absorbs risk, and who captures the margin when code gets cheaper to produce.

The Real Market for Programmers

The standard story says programmers sell skill into an open market and better skill earns better pay. In practice, firms pay more when software is close to revenue, close to operational control, or close to regulated risk.

That is why the same developer can be strategic infrastructure in one company and replaceable delivery capacity in another. The difference is usually not the code. It is the employer's position in the value chain. If software defines the product, pricing power, or operational core, programming labour moves upward in status. If software is treated as implementation overhead, management looks for standardisation, outsourcing, and now AI-assisted compression.

The aggregate data is strong enough on demand. The U.S. Bureau of Labor Statistics projects employment for software developers, quality assurance analysts, and testers to grow 15% from 2024 to 2034, much faster than average, with about 129,200 openings each year on average over the decade (BLS Occupational Outlook Handbook). Median annual pay for software developers was $133,080 in May 2024 (BLS OOH). Useful numbers, but incomplete. They tell you the market is large and still growing. They do not tell you where bargaining power sits inside it.

The real market for programmers is a negotiation over specification, dependency, and risk.

That is also why labour-market language often obscures power. "Talent shortage" can mean several things at once: employers want optionality, workers want bargaining power, platforms want dependence, and states want domestic capability without always paying to build it.

For employers, this changes workforce design. For investors, it changes how to read software margins. For policymakers, it changes what counts as digital capacity. A country can have many coders and still lack control if the decisive layers are imported, licensed, or locked up in contracts.

A Better Taxonomy of Programming Labour

The usual categories — front-end, back-end, full-stack — describe where code sits, not where value sits. They help allocate work. They do not explain bargaining power.

The more useful lens is proximity to economic control. I would divide programming labour into three layers.

• System Architects define boundaries: data structures, interfaces, permission models, service interactions, reliability assumptions, and failure tolerance. Their work shapes future option value.
• Product Engineers translate messy commercial requirements into coherent software under real constraints. They handle ambiguity, trade-offs, and domain logic.
• Implementation Specialists execute bounded tasks inside established frameworks, workflows, and platforms. They remain necessary, but they are the easiest layer to benchmark, template, and compress.

That hierarchy is economic, not moral.

The upper layer captures more than pay. Architects influence vendor choice, cloud design, security posture, and future integration cost. Product engineers determine whether the firm's insight compounds into durable software or degrades into brittle delivery. Implementation specialists sit under the most pressure because their output is easiest to define and compare.

If a role is measured mainly by ticket throughput, management will eventually try to compress its price.

Two adjacent roles matter more than many firms admit.

First, the data strategist: the person who understands what data can be collected, how it can move, who can access it, and where governance becomes competitive advantage.

Second, the regulatory engineer: the person who translates legal, audit, security, and compliance obligations into system controls. In regulated sectors, that role does not support engineering from the side. It decides what can be sold, bought, or deployed.

The diagram above points at those roles, but they are best understood as overlays on the three-layer structure rather than a separate taxonomy. Data strategy and regulatory engineering can sit inside architecture and product work. That is where many firms now create or lose control.

Demand, Pay, and Where Value Is Captured

Programmers do not earn because a language is fashionable. They earn because their employer operates in a sector where software affects margins, switching costs, or regulatory exposure.

That is why labour-market averages mislead boards. They flatten the difference between software as core asset and software as administrative necessity. If you want to understand computer programming jobs, start with the employer's dependence on proprietary systems.

A developer working on pricing logic, transaction systems, underwriting, internal decision engines, or high-dependence SaaS workflows sits closer to value capture than a developer maintaining generic web features in a low-margin setting. Same broad occupation. Different economic position.

I would separate demand into two employer motives:

• Revenue defence: firms pay up when software protects pricing power, retention, speed, or operational exclusivity.
• Cost containment: firms hire cautiously when software is treated as infrastructure overhead and procurement can pressure rates down.

A simple test works well. If this software fails, does the firm lose revenue, lose control, or merely lose convenience? That answer tells you more than the stack.

I am not going to fake precision on salary by role and sector where comparable data is weak. The pattern matters more.

The mistake is to read this as a pure talent story. It is a capital-allocation story. Stronger margins allow firms to buy better labour, but the deeper point is that they can justify it because software sits inside the competitive core.

That is why I am sceptical of broad claims about a universal shortage or oversupply of programmers. There are shortages in some slices of strategic labour and abundance in more commoditised ones. Investors looking at that split through the AI cycle should read The AI Gold Rush through the lens of who captures margin when production gets cheaper but control gets scarcer.

The Hiring Signals That Matter

Most hiring funnels for programmers are built for legibility. Recruiters scan for frameworks. Managers ask for years of experience with a library. Candidates learn to mirror the keywords. Efficient, but weak.

Framework knowledge is perishable, teachable, and easy to mimic. The stronger signal is judgement.

That matters more under AI-assisted development because surface competence is cheaper to simulate. If screening still rewards polish over reasoning, firms will overrate fluency and underrate systems competence.

Teams rarely fail because nobody remembered an API. They fail because nobody understood the system they were changing.

I would rebuild hiring around three signals.

Systems thinking

Can the candidate explain how one decision affects reliability, latency, security boundaries, data quality, and future maintainability elsewhere in the system?

Strong answers include trade-offs. Weak answers stay local.

Problem decomposition

Can the candidate turn a vague business objective into components, dependencies, sequencing, and explicit constraints?

Too many interviews test bounded puzzle-solving rather than the conversion of organisational ambiguity into executable work.

Navigation of abstraction

Can the candidate use managed services, APIs, internal platforms, and generated code without losing sight of what matters underneath?

That is becoming a core marker of seniority. I would rather hire someone who knows when to trust an abstraction and when to inspect below it than someone who can recite syntax under pressure.

Better interview evidence is straightforward:

• Architecture judgement: ask for a time the candidate rejected a faster implementation because it created downstream cost or governance risk.
• Constraint handling: give a scenario with conflicting demands from product, security, and operations.
• Failure literacy: ask what they would monitor after deployment, what they expect to break first, and how they would detect it.

Short coding exercises paired with design review usually reveal more than marathon take-homes or puzzle theatre.

How AI Changes the Programming Role

AI does not collapse programming into one more efficient job. It widens the gap between routine execution and high-judgement control.

The evidence here needs care.

The Copilot experiment by Peng et al. showed faster completion on one bounded JavaScript task (arXiv). McKinsey reported substantial gains on some software tasks in enterprise settings, including writing new code, documentation, and refactoring, but also found that gains fall sharply on higher-complexity work and unfamiliar codebases (McKinsey). And the evidence is not uniform in one direction: a 2025 randomised trial by METR found that experienced open-source developers working in their own mature codebases were actually slower with early-2025 AI tools, while believing they had been faster (METR). GitHub's Octoverse reporting is useful for telemetry on adoption and platform activity — for example, rapid uptake of Copilot among new developers and growth in AI-related repositories — but that is not the same thing as a controlled causal measure of output quality or strategic performance (GitHub Octoverse).

The common pattern is clear enough. Generative systems are strongest on bounded implementation work where patterns are common, interfaces are legible, and success can be checked quickly. They are weaker where the real task is choosing trade-offs under uncertainty, reconciling conflicting constraints, and seeing second-order effects across systems and institutions.

For employers, that matters more than headline claims about speed. Faster output creates durable value only if someone still controls architecture, testing standards, security assumptions, and failure handling. If that control layer is thin, AI raises the speed at which organisations accumulate technical debt and compliance risk.

This is why I do not read AI as a simple substitute for programmers. I read it as a redistribution of value inside the function.

Routine execution becomes easier to buy, benchmark, and pressure on price. High-judgement coordination becomes more valuable because it governs the terms under which machine-assisted output enters production.

The B+ Trap in programming labour

My B+ Trap framework applies directly here. AI lowers the cost of producing plausible work. It does not lower the cost of being wrong in production.

That distinction will reshape hiring and team design. A larger share of the labour pool will be able to generate acceptable-looking code. A smaller share will be able to interrogate edge cases, identify hidden state, reason about failure propagation, and decide whether a generated solution fits the firm's commercial and regulatory position.

The middle gets crowded.

Employers that confuse surface fluency with systems competence will overestimate the depth of their engineering bench. They may think they have upgraded capability when they have only increased output at the implementation layer.

AI also changes supervision ratios. One strong technical lead, product-minded architect, or engineering manager can direct more implementation work than before, whether that work is done by junior staff, contractors, or AI-assisted teams. That increases the span of control of top operators and weakens the position of workers whose contribution sits mainly in straightforward execution.

Seniority is therefore being redefined. Time served and confidence with a stack are weaker signals than the ability to set constraints for systems that combine generated code, managed infrastructure, internal policy, and external dependencies.

I made a related argument in why the best become unbeatable and how to catch up. Once execution gets cheaper, specification, review, and acceptance become scarcer assets.

Contracts, Regulation, and the Next Control Layer

The most important shift in programming work may not happen in the editor at all. It happens in procurement terms, liability clauses, security schedules, audit rights, and model-usage rules.

That is where many organisations now decide which software practices are acceptable.

When firms adopt AI-assisted development, several questions become operational immediately. Who carries responsibility if generated code introduces a security flaw? How is intellectual-property ownership handled when machine-generated output enters commercial software? What code or data can be exposed to external models during development, testing, or debugging? Which jurisdictions govern processing, logging, and retention?

These are not peripheral compliance questions. They shape daily engineering practice.

A development team may want speed. Procurement may require approved environments, audit trails, retention controls, and indemnity language. Legal may restrict external models for sensitive code or data. Security may impose review thresholds that narrow what "automated" can mean in production.

The programming role therefore merges with governance in regulated or security-sensitive settings. That includes:

• Data handling rules: what can move across environments, and under what conditions
• Access-control design: ensuring permissions reflect contractual and legal commitments
• Traceability requirements: making decisions and code paths reviewable after the fact
• Assurance workflows: building review, testing, and escalation paths that satisfy buyers, auditors, and regulators

The programmer who understands those constraints becomes strategically valuable even if they write less raw code than a pure implementation specialist.

Contracts now determine more software behaviour than many engineers want to admit.

That is particularly relevant in Europe, where governance often arrives earlier and more explicitly through procurement and regulation. But the dynamic is broader than Europe. Large enterprises and public buyers are turning AI and software usage into questions of controllability, provenance, and accountability.

If you want to understand the opening this creates from a European policy angle, the right frame is less delay versus speed and more strategic room to shape enforceable norms. That is why I would look at the AI Act delay as a window of opportunity if you use it well. The opportunity is not rhetorical. It lies in who turns regulatory ambiguity into operational advantage before the field hardens.

What Decision-Makers Should Do

The useful response is not panic about automation or nostalgia for hand-coded everything. It is institutional design.

Employers

Do not organise the engineering workforce around stack labels alone. Build role design around economic function.

Separate architecture authority from routine delivery. If nobody owns system boundaries, AI-assisted output will increase local efficiency while multiplying system-level incoherence.

Redesign hiring and promotion around judgement. Reward people who reduce future complexity, not just present throughput.

Move legal, procurement, and security earlier into software decisions. If those functions arrive only at contract signature or deployment review, teams will build processes they later have to unwind.

A practical checklist:

• Map value proximity: identify which programming roles sit closest to revenue, control, and regulated risk.
• Protect apprenticeship: do not let junior development collapse into prompt-and-accept habits with no systems learning.
• Instrument review: track where generated or heavily abstracted code enters critical paths and who approved it.
• Price for resilience: cheap implementation capacity often turns into expensive remediation.

Investors

Stop treating engineering headcount as a simple cost line. In software-heavy businesses, programming labour can be either a moat or a disguised commodity input.

Five diligence questions matter. Who owns the core abstractions? How much product logic is proprietary? Where does contractual risk sit? Can the company still ship under tighter procurement rules? Which parts of the engineering organisation become substitutable as AI use spreads?

The answers usually tell you more than the demo.

Two patterns matter:

• Good pattern: the company uses AI to compress routine implementation while concentrating expert judgement around architecture, safety, and domain logic.
• Bad pattern: the company celebrates higher output but cannot show tighter control over quality, liability, or maintainability.

In the second case, apparent efficiency is often deferred cost.

Policymakers

If states care about digital capacity, they should stop measuring it only through graduate pipelines or startup counts. Sovereign capability also depends on who can specify, audit, procure, and govern software systems under domestic legal conditions.

That means policy should focus on three layers.

First, procurement. Public buyers can shape the market by requiring traceability, security discipline, and meaningful accountability rather than vague AI-compliance theatre.

Second, labour formation. Training systems should produce not just coders, but people who can combine software with systems design, domain knowledge, and regulatory literacy.

Third, institutional retention. If the state can procure software but cannot evaluate it, negotiate its terms, or inspect its dependencies, it does not control digital infrastructure.

Public software capacity is not measured only by how many people can code. It is measured by whether institutions can govern the code they depend on.

The strategic point is simple. Computer programming jobs are now defined less by syntax than by who sets constraints, who owns abstraction, and who absorbs the downside when accelerated implementation goes wrong.

If you want more analysis like this, subscribe to ELECTE's Newsletter. I write weekly on the political economy and governance of AI, with a focus on who controls it, who profits from it, who regulates it, and what it does to markets, contracts, and labour.

Sources

• U.S. Bureau of Labor Statistics: Software Developers, Quality Assurance Analysts, and Testers
• Peng et al., "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot" (arXiv)
• GitHub research summary of the Copilot productivity study
• McKinsey: Unleashing developer productivity with generative AI
• GitHub Octoverse: A new developer joins GitHub every second as AI leads TypeScript to #1

Fabio Lauria

CEO & Founder, ELECTE

Every week, we explore AI without the hype — using data, analysis and an independent perspective.