What is 5 Factor Framework?


The limits of my language mean the limits of my world”

Ludwig Wittgenstein

Do you know the answer to these questions:

What is the nature of reality?

Do we live in a simulation? (Sometimes I have a feeling we are in “vibe-coded simulation”)

What is the color of the most famous internet dress?

What is the point of all of this?

How do we answer those questions related to the world around us?

What thinking tricks do we use to navigate reality?

Reality is too complex.

So the software we deploy.

Some get carried away with vibe coding and forget about that. Then next day they end up on Twitter or offer free tokens through the vibe coded app to a lucky group of hackers first to find them.

We use models to understand, predict, analyze, and act in that complex system.

A model is a simplified version of a complex thing.

Mental model - that is a personal way of representing things.

Another thing - we like to use checklists and recipes.

150 grams of butter.
200 grams of dried tomatoes,…

If you want people to look at you as a weirdo you can say “Do you have Lasagna Bolognese creation framework?” or “Give me a checklist for Pizza Margherita!”

You can, but you shouldn’t.

We can think of frameworks as checklists and recipes.

These are rules and different categories that help us operate the world.

Models live inside the framework and try to give answers to some part of the framework.

Which leads us to my mental shortcut to navigate the messy world of AI-assisted coding.

I call it “5 Factor Framework”. Not totally brand new thing - it just has my own flavors.

5 Factor Framework consists of:

- Context
- Model
- Tools
- Prompt, and (drum roll)
- Orchestrator.

Here is what kind of thinking helped me:

I need somehow to communicate with the machines. Machines used to “understand” assembly, then programming languages. Now they understand spoken and written languages that do not end sentences with semicolons.
Our communication language is now called prompt.
Next, if I ask the machine about something, better it be aware of all supporting information. That is my context - amount of information it needs to process. And there is a catch - too little and they start inventing things, too much and they get lost.
The Goldilocks principle suggests that the ideal amount of information is ‘just right’, not too little and not too much.
Third, models. This time LLM models. Pick up your poison. Some are good at image generation, some are free, others are fast. Pick your hammer.
Further on: tools - currently this is a catch-all category for tools that help LLM do their jobs.
There are also tools that improve prompts, context, and help models.
And the last - deus ex machina, wizard behind the keyboard. Yes, that is you. The Orchestrator.

Example:

If you (Orchestrator) want to generate an image of yourself as part of the Fellowship of the Ring you need to decide which model is best for this.
Let’s say you pick Gemini Nano Banana. Now you provide it with your profile image and reference image from the movie (that is your context). And give it instructions through the prompt “Make me part of the Fellowship of the Ring, and shave the beard of Gandalf” (because it is always good to have fun).
Gemini is working and under the surface it uses different tools and at the end you get your image.

Let’s see how to apply our framework when thinking about different AI engineering terms:
- subagents - they free up context and use its own tools
- mcp servers - mostly focused on tools
- Claude skills - prompt and tools that are working with optimized context
- Claude commands - saved prompts
- etc.

Most of the framework out there forgets the Orchestrator and I would argue that this is the most important part to improve.
Everything falls apart if you are the weakest part of the system.

In summary

Using some kind of framework is handy when dealing with the complexity of reality. This for sure applies to AI-assisted engineering.

Approach this as a scientist - mental models are as good as long as they reflect reality and solve your problems.

If they stop working - pivot and change.

Use this model until you come up with another one.

The main point is you are the Orchestrator - don’t forget yourself.