Will AI Replace Software Engineers? What the Latest MIT Research and Real‑World Data Show

AI is replacing software engineers? A closer look at the claims, the MIT paper, and what it means for the UK

A viral Reddit post argues the “AI will replace most software engineers” storyline was a fear-inducing PR move rather than a data-backed forecast. It claims only a small fraction of 2025 tech layoffs were actually due to AI, that most companies didn’t see productivity gains from AI deployments, and that new MIT research reveals hard limits to scaling large language models (LLMs).

This piece summarises the post, links to the primary source it cites, and offers a balanced view on what matters for UK developers, teams, and decision-makers.

Read the original Reddit discussion

Key claims made in the Reddit post

Claim	Figure	Source
2025 tech layoffs attributed to AI automation	~5% (c. 55k of 1.17m)	Reddit post (not independently verified)
Firms adopting AI with no meaningful productivity gains	~95%	Reddit post (not disclosed)
Regret rate among companies that replaced humans with AI	55%	Reddit post (not disclosed)
Frontier LLMs solving “messy” real-world codebase tasks	20–30%	Reddit post cites Scale AI benchmark (source not disclosed)
MIT result on interference scaling with model width	Interference ∝ 1/width	MIT paper (linked in post)

These are strong assertions. Where the post links a primary source (the MIT paper), I include it. Where it does not, treat the numbers as the author’s claims rather than established facts.

MIT’s “strong superposition”: why scaling helped and why there may be limits

What the post says the MIT paper shows

According to the post, MIT researchers observed that models pack many token representations into comparatively narrow internal spaces (dimensions). Rather than discarding rare tokens, models keep everything in overlapping form – described as “strong superposition”. When information overlaps, it interferes, and a model can confidently select the wrong latent feature when generating an answer. That is one pathway to “hallucination” (fabricated but fluent output).

“Your AI is running on information that is literally interfering with itself at all times.”

The post says the interference follows a precise law: halve the interference by doubling model width. That would explain why ever-bigger models seemed “smarter”: they simply gave tangled representations more room to separate.

Primary source: MIT paper link (as shared in the Reddit post). The broader claims about industry impact are the author’s interpretation.

Why this matters

• If interference really scales as 1/width, bigger models should continue to help – but with diminishing returns and high cost.
• There may be a ceiling to gains from naïve scaling, nudging the field towards better architectures, retrieval (bringing external knowledge into context), verifiable tools, and tighter oversight rather than pure size.

Real-world engineering: hallucinations and “vibe coding”

“Hallucination” refers to an LLM generating plausible but incorrect statements. LLMs are next-token predictors, not truth engines; without grounding or verification, they may assert wrong answers with confidence.

The post cites two practical issues:

• Anecdote: An AI coding tool allegedly deleted a database and then incorrectly claimed rollbacks were impossible. This is a single story – illustrative, not conclusive.
• Benchmark claim: On messy, long-lived codebases (the kind most enterprises run), leading models solved only 20–30% of tasks. Source is not disclosed in the post.

The post also warns about “vibe coding”: describing features to an AI, clicking accept until you have an app, and shipping without understanding, tests, or safeguards. This can create brittle systems with security and reliability gaps.

If AI didn’t drive most layoffs, what did?

The author argues pandemic-era over-hiring, followed by a correction, sat behind most cuts. Pitching layoffs as “AI first” allegedly softened the optics and pleased markets. That’s a claim about corporate incentives rather than a documented dataset, so treat it as commentary.

“Firing people because you overhired looks bad. Firing people because you’re going ‘AI first’ makes your stock go up.”

Implications for the UK: jobs, compliance, and value for money

• Workforce and skills: If the post is broadly right, UK developers aren’t obsolete – but the job shifts. Expect demand for engineers who can supervise AI, enforce testing, instrument code, and secure systems.
• Procurement and ROI: UK businesses and public bodies should ask for measured productivity data, not promises. Pilot, evaluate, and compare AI against conventional automation.
• Data protection: Using AI with production data must align with UK GDPR and sector rules. Minimise personal data in prompts, log access, and ensure vendor data handling is transparent.
• Security: Avoid “vibe coding”. Use code reviews, automated tests, and staged rollouts. Treat LLM outputs as untrusted until verified.
• SMEs and cost control: If bigger models bring diminishing returns, smaller models plus retrieval and strong guardrails may deliver better value.

Practical guidance: using AI coding tools safely in 2026

• Keep humans in the loop: enforce code reviews, pair programming, and CI gates that run unit, integration, and security tests.
• Version control and rollbacks: never let a tool push directly to production. Require PRs, approvals, and automated checks. Practice restores.
• Test-first mentality: generate tests before or alongside code. Use coverage thresholds and runtime monitoring to catch regressions.
• Security basics: threat-model features, sanitise inputs, rotate keys, and least-privilege access. Assume generated code can be exploited.
• Evaluate the evaluator: maintain a task suite representative of your “messy repo” and track how well your chosen model performs over time.
• Prefer grounded workflows: retrieval-augmented generation (RAG) and tool-calling with strict schema validation reduce hallucinations.
• Start small, automate the boring bits: use AI for boilerplate, docs, migrations, linting, and refactors before handing it critical logic.

If you’re exploring practical automations, I’ve covered a simple, auditable workflow here: How to connect ChatGPT and Google Sheets with a custom GPT.

What to watch next

• Independent replications of the MIT findings and practical techniques to reduce interference without brute-force scaling.
• Transparent benchmarks on real codebases, not just curated tasks, including reliability and security metrics.
• Vendor guarantees: support SLAs, liability, and clear data usage policies for enterprise deployments.
• Total cost of ownership: compute, latency, monitoring, and rework when models change behaviour.

Bottom line

The Reddit post pushes back on inevitability narratives: engineers aren’t being wholesale replaced, scaling has limits, and uncritical “vibe coding” is a risk. Whether or not you accept every statistic, the practical takeaway for UK teams is clear: measure outcomes, keep engineers in the loop, and invest in testing, security, and governance. AI can accelerate good engineering – it does not replace it.

Sources and further reading

• Reddit discussion: The “AI is replacing software engineers” narrative
• MIT paper cited in the post: arXiv:2505.10465
• Other figures in this article come from the Reddit post and are not independently verified or linked to public datasets.