From Prompt Engineering to Loop Engineering: Four Stages, One Move from Word and Excel into Polarion

Three years ago the whole game was picking better words for a single prompt. Today the people who work fastest with AI barely write prompts at all. They write the systems that write the prompts.

That shift did not happen in one jump. It happened in four stages, and each stage has a name: prompt engineering, context engineering, skill engineering, and loop engineering. Each one solves a problem the previous one could not, and each one wraps the last rather than replacing it.

I want to walk that road with you, and I want to do it with one very ordinary problem that runs from the first stage to the last: taking an old product whose requirements live in Word and Excel, and rebuilding it properly in Polarion. By the end you will know exactly what each term means, where one stage stops and the next begins, and roughly where you sit on that road today.

Table of contents

1. The problem: ten years of Word and Excel, now moving into Polarion
2. Stage 1: Prompt engineering, where we started
3. Stage 2: Context engineering, everything the model sees
4. Stage 3: Skill engineering, packaging the procedure once
5. Stage 4: Loop engineering, where we stand now
6. All four at a glance
7. The through-line: four words, one mental model
8. Checklist: which stage are you actually on?

The problem: ten years of Word and Excel, now moving into Polarion

Every abstract idea in this post gets easier if we hang it on something real, so here is the case that runs through all four stages.

Picture a product that has been around for ten years. The requirements live in a pile of Word documents, each a slightly different template, written by different people over the years. The test cases and the traceability sit in a set of Excel sheets, colour-coded in ways only two people still understand. It worked, more or less. Now the company commits to Polarion, and someone has to rebuild the whole thing there: requirements as proper work items, the document structure as LiveDocs, the coverage as real links, the tests as test cases.

It is hundreds of requirements across dozens of files. You can copy and paste for a month, or you can point AI at it. This post is about the second option, and specifically about how the way you point AI at it has changed four times in three years.

The tell that matters is this: turning one messy Word paragraph into a clean, well-formed Polarion work item feels like magic. Doing that eight hundred times in a row is soul-crushing. The distance between "one work item looks great" and "the whole project stands in Polarion, structured, linked and nothing dropped" is the exact distance from stage one to stage four. Let us start at the beginning.

Stage 1: Prompt engineering, where we started

The goal of this stage is narrow and honest: get the model to do one thing well. Turn this one requirement into a clean work item. Rewrite this vague sentence so it is testable. Summarise this Excel row. Nothing more.