Skip to content
AI Doesn't Need Less Process. It Needs Better Process.
AI-Native Methodology 10 August 2026 · 4 min read

AI Doesn't Need Less Process. It Needs Better Process.

OB
Ofer Biran

Let’s talk about the moment you realize that hitting warp speed without a navigation system just means you’re going to crash into a planet much faster. 🚀

For years, our industry’s holy grail has been velocity. I’ve spent a massive chunk of my career trying to make high-performing teams even faster. We optimized sprints, cleared pipelines, and hunted down dependencies with the relentless focus of Liam Neeson looking for his daughter.

Then AI dropped into our laps and changed the equation. Things that used to take hours or days could suddenly happen in minutes. It should have felt like the ultimate victory.

Instead, somewhere between watching AI produce in thirty seconds what used to take a team significantly longer, I realized something uncomfortable: speed was never really the core problem. The real challenge has always been making sure we’re actually heading in the right direction.

When I first started using AI heavily in my own work, I treated it like a wildly caffeinated, incredibly fast junior developer. Give it a task, get an output, iterate. It was astonishingly fast, but it was also perfectly capable of implementing a fundamentally flawed idea, forgetting decisions we’d already made, and then confidently explaining why its new version made perfect sense.

That’s where the real problem started to become interesting.

In a traditional games studio, a good team carries an enormous amount of invisible context. A Tech Artist remembers a pipeline limitation from six months ago. A QA engineer spots the nightmare edge case before it reaches the sprint backlog. A developer looks at a requirement and says, “We can do that, but I’m not sure we should.”

Humans complain when things don’t make sense.

AI is dangerously polite.

It will happily build exactly what you asked for, including the parts you didn’t realize you were asking for.

A vague requirement executed slowly creates waste. A vague requirement executed instantly creates very efficient waste.

That changed the way I started thinking about process. If execution is no longer the expensive part of the equation, then the value shifts somewhere else. Suddenly, the boring things — ownership, acceptance criteria, dependencies, quality gates — become much more important.

Traditional delivery can survive a certain amount of ambiguity because people continuously course-correct. Someone asks a question. Someone challenges an assumption. Someone notices that what we’re building doesn’t actually match what we intended.

When execution happens at AI speed, waiting until the end to discover you’re wrong becomes dangerous. You may already have ten layers of beautifully functioning nonsense sitting on top of the original mistake.

So I’ve found myself moving more of the quality thinking upstream. Not more documentation for the sake of documentation — more clarity.

What are the boundaries? What decisions have already been made? What does “done” actually mean? What should the AI check before continuing? And when should it stop and ask a human?

The more I build with AI, the more convinced I become that the interesting challenge isn’t the prompt. It’s the system around the prompt.

That leads to the question I care about most professionally: what happens to Production and Program leadership?

There’s an understandable fear that if AI can manage tasks, flag dependencies, generate documentation and write status reports — which, let’s be honest, I’ve written enough of for one lifetime — then Production and Program roles become less valuable.

I think parts of the job probably will disappear, and I’m completely fine with that. The highest value of Production was never writing status updates or moving Jira tickets around. It was creating an environment where a group of people could reliably turn intent into something real.

AI changes the ingredients. It doesn’t remove the responsibility.

Which means I increasingly think our jobs are moving from coordinating the doing toward designing the environment where the doing happens.

How does information flow? Where do decisions live? Who owns the outcome? What can AI decide on its own? Where does a human need to intervene? How do we scale velocity without scaling the chaos?

Those feel much more like leadership questions than technology questions.

And that’s the part I didn’t expect when I started experimenting with AI. I thought I was going to learn how much process it could remove. Instead, it made me appreciate why some of that process existed in the first place.

I don’t think AI needs more bureaucracy, and it definitely doesn’t need an “AI Steering Committee” to approve the AI Steering Committee.

It needs better process: clear intent, visible decisions, defined ownership, useful checkpoints, and humans who know when to trust the system and when to challenge it.

So, to anyone hoping AI was finally going to rid the industry of Production and Program people:

Sorry.

We’re going to need another Jira license. 😉