Jason Lemkin laid it out on 20VC this month. The AI era has had three phases.
Phase 1 was too technical. Only engineers could touch it. If you wanted to automate something, you needed to write code, manage APIs, and deal with infrastructure. The people who understood the broken processes weren't the ones who could fix them.
Phase 2 was prompt engineering. The tools opened up a bit, but you still had to torture them into doing what you wanted. You could make things work, but it required a specific kind of patience and fluency that most operators didn't have time to develop.
Phase 3 is now. In Lemkin's words: "Mere ordinarily smart generalists can make these tools do magical things."
Why this shift matters for operations teams
The most important thing about this phase isn't the AI getting better. It's who gets to use it.
The person who understands a broken process best is the person stuck inside it. The CSM who manually assembles QBR decks every quarter. The sales rep who Googles prospects one by one. The founder who opens five tabs before every customer call. These people have always known exactly what should be automated. They just couldn't do anything about it.
That's changing. The gap between "I know what needs to happen" and "I can make it happen" is collapsing. You don't need to know how to write code to describe a workflow in plain language and have it run.
"Pick yourself off the ground. This is your time."
Lemkin's point isn't just observational. It's a call to action. The people who have been waiting for automation tools to get easy enough are out of excuses. The tools are there. The barrier isn't technical skill anymore. It's just deciding to do it.
The operators, the generalists, the people who have been manually holding processes together with spreadsheets and willpower are the ones best positioned to build automations that actually work. They know the edge cases. They know which steps get skipped. They know what breaks on Fridays at 4pm.
What changes when the operator builds the automation
When technical skill was the bottleneck, automation projects went through a translation layer. An operator would describe what they needed. A developer would interpret it. Something would get built. It would be close but not quite right. Iteration cycles were long. Half the projects died in the gap between "what I asked for" and "what got built."
Nobody understands a broken process better than the person stuck inside it. Now they can actually do something about it.