The PER Model: My Operating Model for Working With AI

I’ve been thinking a lot about how we actually work with AI.

Not just whether AI is useful. That part is obvious enough now. More specifically, I’ve been thinking about the operating model around it.

Where should the human be involved?

Where should AI take over?

When should you trust it?

When should you slow it down?

And how does that change depending on whether you are writing code, planning work, reviewing output, drafting content, or operating as an engineering manager?

The model I keep coming back to is simple:

Plan. Execute. Review.

Or, PER, who doesn’t love an acronym.

I am not claiming this is some entirely new invention. It is more that this is the model I have landed on after using AI heavily for a while, especially in software engineering and engineering management contexts.

The useful part of the model is not that there are three steps. That part is obvious. The useful part is that each step has a different level of human involvement.

The basic model

The PER model breaks AI-assisted work into three parts:

1. Plan
2. Execute
3. Review

At a glance, it looks simple.

You plan the work, AI executes the work, and then you review what came back.

But the nuance is in how much control you give AI at each stage.

A lot of AI workflows are described as a kind of sandwich:

Human → AI → Human

The human gives instructions, AI does the work, and the human checks the result.

That is broadly right, but I think it is too generic. It does not really help you decide how involved you should be at each stage, or how that should change based on the risk and type of work.

PER gives me a more practical way to think about it.

Planning: where the human role varies the most

Planning is the most interesting part of the model because this is where the human involvement can vary significantly.

I currently think about planning in three modes.

1. Human-led planning

This is where I already know exactly what I want.

I write the plan. I define the direction. I decide the shape of the work.

AI might still be useful here, but mostly as a formatting or translation layer. For example, I might write a rough plan and ask AI to turn it into a clearer spec that a coding agent can execute.

In this mode, the thinking is mine.

AI is helping me package the thinking into something more usable.

This is useful when the work is important, nuanced, high-risk, or tightly connected to context that I understand better than the model.

2. Collaborative planning

This is the mode I use the most.

I have a clear idea of what I want, but I want to work through it with AI. Matt Pococks Grill Me skill is quite good for this.

I might start with a rough direction and then use AI to challenge it, expand it, ask questions, or help me find gaps.

This is where I’ve changed my thinking the most.

For a long time, I strongly agreed with the idea of:

Outsource your typing, not your thinking.

That still has some truth to it. But I no longer think it fully captures how I work with AI.

There are times where AI contributes something useful to the thinking process. It might identify a missing consideration. It might suggest a cleaner structure. It might say something that aligns closely with what I was already thinking, but phrases it better. Or it might push the idea in a direction that is genuinely better.

That does not mean I blindly accept the output.

The important distinction is this:

You can outsource some thinking, but you should not outsource your understanding.

That framing resonates more with how I work now.

I am happy to use AI as a thinking partner. But by the end of the planning process, I need to understand the plan. I need to be able to explain it. I need to know why we are doing it that way.

If I do not understand the plan, I have not really delegated the work. I have just created risk.

3. AI-led planning

The third mode is where I hand off more of the planning to AI.

This is useful when the work is low-risk, exploratory, or disposable.

For example, if I am doing a quick spike, testing an idea, or asking AI to generate a possible direction that I may throw away later, I am more comfortable giving it a loose prompt and seeing what it produces.

In this mode, I am not trying to perfectly control the shape of the plan upfront.

I am using AI to create momentum.

That said, I still need to review the plan before trusting the execution. The level of review depends on the risk, but I do not want to be in a position where I am executing something I do not understand.

Execution: let AI do the work

Execution is the part where I am most opinionated.

For coding workflows especially, I think execution should be AI-driven.

If the plan is clear and the harness is good, AI should be doing the implementation.

That does not mean the output will always be right. It will not. But if something goes wrong, I would rather improve the harness, improve the instructions, improve the tests, improve the plan, or improve the review loop than manually patch the result myself every time.

Manual patching can feel faster in the moment, but it often avoids the real problem.

If the AI made a mistake because the plan was unclear, fix the plan.

If it made a mistake because the tests did not catch something, improve the tests.

If it misunderstood the codebase, improve the context it was given.

If it keeps making the same class of mistake, improve the workflow around it.

The goal is not just to get one task done, the goal is to improve the system so the next task goes better, just like what you would expect from an engineer improving their craft.

That is what I mean by harnessing. The human should not necessarily be doing the execution. The human should be shaping the environment that allows AI to execute well, again, same thing we do with DX (Developer Experience) with engineers.

This idea applies most clearly to code, but it also applies more broadly.

If AI is generating a draft, producing a campaign, summarising research, or creating a plan, the execution step is where you let it produce the artefact.

Then you review.

Review: where trust is earned

Review is the step that keeps the whole model grounded.

Once AI has executed, you need to inspect the output.

Did it follow the plan?

Did it solve the actual problem?

Did it introduce new issues?

Did it make assumptions that were not valid?

Did it technically complete the task while missing the intent?

For now, I think about review in two main modes.

1. Manual review

This is the obvious one.

You look at the output yourself.

If it is code, you inspect the diff, run the tests, use the product, and check the behaviour.

If it is writing, you read it and decide whether it sounds like you, whether the argument holds together, and whether it says what you actually wanted to say.

If it is planning work, you check whether the structure is sensible, whether the dependencies are right, and whether the recommendations match reality.

Manual review is still essential, especially for anything important.

2. AI-assisted review

The second mode is bringing AI into the review step.

This might mean asking another model to review the output against the original plan. It might mean having a critique pass. It might mean using an AI reviewer as part of a coding harness. It might mean having a separate model identify risks, inconsistencies, or missing requirements.

I generally prefer a separate review step rather than treating review as part of execution. This does not mean that the agent is lacking tools to perform verification during its execution, which is a deal breaker and must be in place, otherwise its implementing blind, verification must be part of the ADE (Agentic Development Environment).

There is value in having another pass that asks:

“Given the plan, did we actually do this correctly?”

That review can then feed back into the loop.

If something is wrong, you refine the plan, execute again, and review again.

That is the cycle.

Is there a third review mode?

There might be a third mode, but I am less certain about it.

The possible third mode is risk-based automated review.

For low-risk tasks, maybe the system can review itself against a defined set of requirements and ship if everything passes.

For example, if the work is small, reversible, well-tested, and low impact, perhaps a human does not need to manually inspect every detail.

But for higher-risk work, there still needs to be human involvement.

I do not think I have fully landed on this yet. It feels directionally right, but the details matter.

The review process needs to be tied to risk.

Not all work deserves the same level of scrutiny. But not all work can be safely delegated either.

The human does not disappear

A common mistake in AI workflows is assuming the goal is to remove the human. I do not think that is the goal.

The goal is to move the human to the right part of the system.

Sometimes that means being deeply involved in planning.

Sometimes that means shaping the harness and letting AI execute.

Sometimes that means reviewing the final output carefully.

Sometimes that means using AI to critique what another AI produced.

The human role changes, but it does not disappear, well yes maybe there are some scenarios where this happens but for me those are extremely rare, the sharpest of edge cases.

For me, the most important principle is still understanding.

If I collaborate with AI on a plan, I need to understand the plan.

If AI writes code, I need to understand the shape of the change.

If AI produces a recommendation, I need to understand the reasoning well enough to decide whether I trust it.

I do not need to type every line.

I do not need to manually perform every step.

But I do need to understand what is happening.

Why this model works for me

The reason I keep coming back to PER is that it gives me a simple way to decide how to work with AI.

Before starting a task, I can ask:

How involved do I need to be in planning?

Do I already know exactly what I want, or should I collaborate with AI to shape the plan?

Can AI execute this safely?

Is the harness good enough? Are the instructions clear enough? Is the task scoped well enough?

What level of review does this need?

Do I need to manually inspect it? Can I use AI to assist the review? Is the work low-risk enough that an automated review might be sufficient?

Those questions are more useful to me than broad statements about whether AI should or should not be trusted.

Trust is contextual, but always a requirement.

The right operating model depends on the work.

The loop matters

PER is not always a straight line.

It is usually a loop.

You plan, execute, review, and then often go back to planning.

The review step might reveal that the plan was incomplete.

Execution might show that an assumption was wrong.

The output might be technically correct but strategically off.

That is normal. It happens in software engineering without AI as well.

The point of the model is not to make everything perfect on the first pass. I am not a one-shot person, its all about iteration for me.

The point is to create a clear loop for improving the work.

Final thoughts

The PER model is the operating model I am using right now:

Plan. Execute. Review.

Planning is where human involvement varies the most.

Execution is where AI should often do the work (yes this means you still should hand write code sometimes, be practical), especially in coding workflows.

Review is where trust is earned and the loop improves.

The biggest shift in my thinking is that I no longer fully agree with the idea that you should only outsource typing and never thinking.

I think AI can be useful in the thinking process.

But you cannot outsource your understanding.

That is the line that matters.

Use AI to help plan. Let it execute where the harness supports it. Use review to catch gaps, improve the system, and decide whether the result is good enough.

That is the model I am using for now, and I expect I will keep refining it as the tools and workflows continue to evolve.