There is a hiring conversation that captures where this is all going. A candidate for a platform team lead was asked about the on-prem Kubernetes SREs who, famously, do not want to write code. They want to run systems, not be engineers. His answer was one sentence: but with AI, everybody is an engineer. He got the offer mid-interview.
That line is worth sitting with, because it reframes what AI actually does to an organization. Most of the conversation about AI coding treats it as a productivity multiplier for people who already write code. Faster engineers, more output per engineer, the same team shipping more. That is real, but it is the small version of the story. The bigger version is that AI does not just speed up engineers. It changes who counts as one.
The SRE who never wanted to write code was making a rational choice about friction. Writing code is a skill, it takes years, and if your job is keeping systems alive you had every reason to stay on your side of the line. AI collapses that friction. When you can describe what you want and get working software back, the reason to refuse evaporates. The reluctance was never about the goal. It was about the cost of getting there, and the cost just dropped to near zero.
This is why I keep saying that agents are about to break out of engineering. The primitive that used to belong to a walled-off team now shows up everywhere. Sales runs agents. Ops runs agents. The person who would have filed a ticket and waited two sprints now ships the change themselves. The E in SRE always stood for engineering. AI just makes that impossible to ignore.
So the practical question for leadership is not whether to give your engineers AI tools. It is whether your org chart still makes sense when everyone can produce software. If engineering is a small department that everyone else routes requests to, you are structured for a world that is ending. Staff for a world where every function touches code, where review and approval matter more than authorship, and where the bottleneck is taste and judgment rather than who knows the syntax. The candidate saw it in one sentence during an interview. The question is whether your organization sees it before the reorg gets forced on you.
Key takeaways
- The objection that some ops people 'don't want to write code' dissolves when AI turns intent into working code.
- AI does not just make engineers faster - it expands who counts as an engineer at all.
- Organizations should staff and structure for a world where everyone touches software, not just a walled-off engineering team.
FAQ
Does 'everybody is an engineer' mean we don't need real engineers?
No. Deep systems work still demands expertise. It means the boundary expands - people who would never have written code now ship working software with AI, so the org can no longer treat engineering as a small walled garden.
What about SREs and ops people who don't want to code?
The 'don't want to' framing assumes coding is a high-friction chore. When AI lowers the friction, the reluctance loses its footing. The E in SRE was always engineering - AI just makes that unavoidable.
Related Essays
Agents Are About to Break Out of Engineering
Non-engineering agents are easier to build but harder to contextualize. The organizational knowledge layer — not the execution layer — is the real unsolved problem.
The Operator Should Own the Agent, Not the Developer
The default move when a company needs an agent is to hire a developer. That is backwards. Individual agents belong to operational thinkers, not engineers.
The Primitives Are the Same Across Roles
Sandbox, tools, prompts, governance — the primitives are universal. Engineering agents and GTM agents share the same engine. Only the body changes.
Drowning in pull requests that need your review? Try Tembo Review, a beautiful AI-assisted PR review tool unlike anything you’ve used.