The future of software engineering is SRE

Original Article ↗ Hacker News Discussion ↗

What SRE Is (and Isn’t)

  • Several commenters note the article never defines SRE; others clarify it as “site reliability engineering,” roughly the modern evolution of sysadmin/ops with a focus on uptime, monitoring, and production systems.
  • Debate on scope: some see SRE as mostly web/SaaS; others point out reliability roles exist across many non-web domains.
  • Some argue many “SRE” titles are actually just traditional ops/on‑call roles with new branding.

SRE vs SWE, QA, and Authority

  • Many push back on “everyone becomes SRE”: good developers and good SREs often have different mindsets (innovative vs conservative, feature vs reliability focus).
  • SRE is said to work at Google because SREs can block launches and demand fixes; without that authority you’re just an on‑call engineer with pager duty.
  • Others counter that if all engineers share on‑call, they quickly learn to build more reliable systems.
  • Boundary with QA is fuzzy: some say SREs focus on infra/SLAs, not business correctness; others insist senior SREs must understand product and customers to prioritize work.

AI, Automation, and the SRE Future

  • Core premise discussed: as LLMs make code cheaper, complements like testing, review, and operations gain value. Some strongly agree; others think these complements will also be automated.
  • Multiple SREs and ops people report outages caused by “AI slop” and say current models are bad at real SRE work, including basic tasks like adding observability.
  • There’s deep disagreement on AI trajectory:
    • One camp says current LLMs are brittle reasoners and won’t soon replace SRE.
    • Another asserts no role is safe; as AI improves, SRE/ops will also be automated (“AI SRE” agents already being built).

Scale, Platforms, and Where SRE Matters

  • Distinction drawn between:
    • Small shops: simple monolith + managed platforms (Cloud Run/Fargate/etc.) where dedicated SRE/DevOps is often unnecessary.
    • Large, complex organizations: many teams, legacy systems, strict SLAs, cost–scaling tradeoffs, and heavy Kubernetes/platform complexity where SRE is essential.
  • Some blame Kubernetes and its ecosystem for unnecessary complexity and “platform engineering” overhead; others say k8s is a solid substrate but most orgs actually want a higher‑level platform.

Future Roles and Job Market

  • Competing visions:
    • “Future is SRE/operational engineer” who understands both code and reliability.
    • “Future is T‑shaped product engineer” combining dev with product/UX, with SRE as a separate specialty.
  • Several foresee fewer total engineering roles, with juniors/bootcamp devs and middle management especially at risk, while a smaller number of senior engineers orchestrate AI agents and own reliability.
  • Widespread concern that SREs will be left cleaning up for low‑quality, AI‑generated “vibe‑coded” systems without adequate mandate or staffing.