Programming Languages Matter Less. Software Engineering Matters More.

Do programming languages still matter in the age of AI? Less as a measure of who can produce code, and more as a set of system constraints. AI can generate Java, Go, Python, Rust, or TypeScript on demand. It cannot make their runtime, memory, concurrency, security, ecosystem, and maintenance trade-offs disappear. Syntax is getting cheaper. Engineering judgment is not.

That distinction matters because the headline version—“programming languages do not matter anymore”—is almost right in the least useful way. Teams are writing less routine code by hand and producing more software with coding agents. But the faster code arrives, the more valuable it becomes to know what should exist, how the pieces should fit, what the runtime will do under pressure, and how another person will safely change the system two years from now.

What does “programming languages matter less” actually mean?

It means the market value of translating a clear requirement into valid syntax is falling. It does not mean implementation choices have become interchangeable. A coding agent can translate a data transformation from Python to Go in minutes. Whether that transformation belongs in a request handler, a queue worker, a database query, a stream processor, or nowhere at all is a different class of decision.

GitHub’s survey of 2,000 enterprise software-team respondents across the US, Brazil, Germany, and India found that 60–71% said AI tools made adopting a new language or understanding an existing codebase easy. That is a real erosion of language barriers. It is not evidence that the consequences of language choice have vanished.

Are developers really writing less code by hand?

There is no global meter for hand-written versus AI-written code, so any universal percentage would be theatre. The direction, however, is visible across usage studies. Stack Overflow’s 2025 Developer Survey reported that 84% of respondents used or planned to use AI tools. Among developers partially using AI in their workflow, writing code was the most common reported use at 59%.

Inside Anthropic—a vendor and therefore not a neutral population—132 engineers and researchers self-reported using Claude in 59% of their work and a 50% productivity gain. Anthropic also observed a 67% rise in merged pull requests per engineer per day. The useful signal is not the exact self-reported uplift. It is the shape of the change: slightly less time per task, considerably more output, and 27% of AI-assisted work consisting of tasks that otherwise would not have been done.

Anthropic’s earlier study of 500,000 coding interactions found that 79% of Claude Code conversations were classified as automation, versus 21% augmentation. By June 2026, its analysis of roughly 400,000 Claude Code sessions described the division of labour even more clearly: people made most planning decisions—what to do—while Claude made most execution decisions—how to do it.

Does AI make software expertise less important?

No. It changes which expertise pays.

In Anthropic’s June 2026 research, sessions rated novice reached verified success 15% of the time. Intermediate or expert sessions reached 28–33%. The researchers found that the more domain expertise a person brought, the more work the agent completed per instruction. Their conclusion is unusually direct: steering an agent toward success depended more on command of the domain than on the ability to write code.

This is the shift in one sentence:

"When code becomes abundant, judgment becomes the scarce input. The valuable engineer is no longer the person who can type the most implementation. It is the person who can decide what should be built, constrain the agent, and prove the result deserves to run."

That does not mean every architect wins and every programmer loses. Architecture without implementation feedback becomes PowerPoint. The strongest engineers stay close enough to code, traces, databases, queues, deployment pipelines, and incidents to know when the system model is wrong. They simply spend less of their scarce attention typing predictable code.

Why did the productivity evidence look contradictory?

Because “AI makes developers faster” is not one experiment. Task familiarity, tool generation, repository quality, developer skill, review latency, and whether agents run in parallel all change the outcome.

METR’s controlled early-2025 study found experienced open-source developers took 19% longer with AI on tasks in codebases they knew deeply. In February 2026, METR reported that later data pointed toward a speedup, but warned that selection effects and unreliable time measurement made the estimate weak. Its honest update says developers were likely more accelerated by early 2026, but the size of the gain could not be measured reliably.

DORA’s 2025 research resolves much of the apparent conflict: AI is an amplifier. It found positive relationships with throughput and product performance, while the relationship with software-delivery stability remained negative. In plain language, AI pushes more change through the system and exposes weak testing, oversized batches, slow feedback, and poor platform engineering downstream.

So the right question is not “How much faster does AI make a developer?” It is “What happens to the whole delivery system when implementation throughput rises?” If review, tests, architecture decisions, security checks, deployment safety, and observability do not scale with generation, the company produces more risk per week, not more value.

Why do programming languages still matter?

Because a language is not merely its syntax. It is a bundle of defaults and guarantees that survives after the agent closes the pull request.

Runtime behaviour still reaches the invoice

Garbage collection, startup time, JIT warm-up, event loops, thread scheduling, async runtimes, binary size, and foreign-function boundaries affect latency, infrastructure cost, deployability, and failure modes. An LLM can write both implementations. Production still pays for the one you choose.

Memory models still reach security

Google’s Android team offers a rare real-world comparison. Its 2025 data reported that memory-safety vulnerabilities had fallen below 20% of Android vulnerabilities as the platform shifted new native development toward Rust. Google estimated a more than 1,000× lower memory-safety vulnerability density for Rust than its historical C and C++ code; Rust changes also had a four-times lower rollback rate and spent 25% less time in code review.

Those figures are specific to Android and should not be pasted onto every team. They still destroy the claim that language choice no longer matters. CISA likewise recommends memory-safe languages for new product lines and phased migration of exposed or privileged components. AI makes writing either language easier; it does not repeal their safety models.

Type systems and concurrency models still shape failure

A compiler that makes invalid states hard to express changes what an agent can accidentally ship. Ownership, nullability, algebraic data types, effect boundaries, structured concurrency, and race detection are not aesthetic preferences. They move defects from production into generation or compilation, where they are cheaper to catch.

Ecosystems still determine whether you can operate the result

Package maturity, security response, database drivers, observability tooling, cloud support, hiring depth, release cadence, and long-term governance matter more than whether an agent can generate a function. A language with a perfect benchmark and a thin operational ecosystem may be the expensive choice.

What becomes more important than language fluency?

1. System design. Boundaries, data ownership, failure isolation, consistency choices, integration contracts, and the ability to change one part without understanding everything.
2. Runtime literacy. Knowing what code becomes after compilation or interpretation: allocations, syscalls, processes, threads, event loops, network connections, database locks, caches, and queues.
3. Architecture with evidence. Fitness functions, dependency rules, contract tests, performance budgets, threat models, and observability that turn diagrams into enforceable constraints.
4. Domain modelling. The rules the model cannot infer from a ticket: who owns the money, when an order is final, what “deleted” means, which state transitions are legal, and which mistakes are irreversible.
5. Verification. Tests, static analysis, review, fuzzing, load tests, migrations, rollback plans, and production telemetry. Generation scales only when rejection scales too.
6. Maintainability. Naming, cohesion, small interfaces, documented decisions, dependency restraint, deletion, and a codebase a new human can understand without asking the original prompt.
7. Technical leadership. Scoping work, sequencing risk, setting standards, deciding when not to automate, and keeping ownership inside the team.

This extends our earlier argument that context, not raw intelligence, is the coding-agent bottleneck. Context tells the agent what exists. Engineering judgment tells it what should exist and how you will know it is safe.

How should a CTO choose a programming language now?

Choose for the system and the organisation, not for the agent. Agents weaken the cost of unfamiliar syntax, which means teams can give more weight to the properties that last.

The fashionable stack is rarely the answer. The answer is usually a boring primary stack the team can operate, plus a deliberate exception where a different runtime or safety model creates measurable value. AI makes those exceptions cheaper to implement. It does not make them free to own.

How do you keep AI-generated code maintainable?

1. Write constraints before prompts. Record architecture boundaries, non-functional requirements, prohibited dependencies, data rules, and acceptance tests in the repository.
2. Keep changes small. One bounded intent per pull request. Large generated diffs turn human review into ceremonial approval.
3. Make the architecture executable. Use dependency tests, linters, schemas, API contracts, policy-as-code, and performance budgets so violations fail automatically.
4. Test properties, not only examples. Ask what must always be true under invalid input, retries, concurrency, partial failure, and adversarial behaviour.
5. Review the design before the diff. A flawless implementation of the wrong boundary is still wrong. Approve the plan, then let the agent execute.
6. Track system outcomes. Measure change-failure rate, review time, escaped defects, incident load, cost per successful task, and time to restore—not lines produced.
7. Delete aggressively. AI makes code cheap to add. A strong team uses that speed to test ideas and then removes the losing implementation, its dependency, and its abstraction.

If your team already has a fast-growing AI-generated codebase, start with our QA checklist for AI-generated code or the more operational production-readiness checklist. The goal is not to prove that the agent wrote bad code. It is to prove that the system is safe to own.

What should companies hire for in an AI-first engineering team?

Hire people who can move between levels. They can explain the customer rule, sketch the data flow, predict the runtime consequence, inspect the generated code, design the test, read the production trace, and make the trade-off legible to the business. A pure syntax specialist is easier to substitute. A person who owns outcomes across those layers becomes more valuable.

For junior engineers, this does not mean skipping programming fundamentals. You cannot review memory, concurrency, database, or security behaviour you have never learned to see. Use AI to accelerate practice, not to avoid building a mental model. For senior engineers, it means turning tacit judgment into repository-visible constraints that agents and less experienced colleagues can both follow.

Sources and research notes

• Anthropic, Agentic coding and persistent returns to expertise, 16 June 2026 — approximately 400,000 Claude Code sessions; vendor data, transcript-classifier limitations stated by the authors.
• Anthropic, How AI is transforming work at Anthropic, 2 December 2025 — internal survey, interviews and usage data; not a representative sample of all developers.
• DORA, State of AI-assisted Software Development 2025 — AI as an amplifier of the underlying delivery system.
• Stack Overflow Developer Survey 2025: AI — adoption and trust data from 49,000-plus respondents overall.
• METR, developer productivity experiment update, 24 February 2026 — why later speedup estimates remain uncertain.
• GitHub, enterprise developer survey on AI coding tools, updated 15 April 2025 — cross-language and codebase-understanding perceptions.
• Google Android Security, Rust in Android: move fast and fix things, 13 November 2025 — Android-specific security, rollback and review data.