Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
If polishing prompts is no longer improving an AI workflow, the next issue may be missing context, weak runtime checks, or a task that needs a controlled sequence of steps. Jason Yang’s four-layer framework—prompt, context, harness, and loop—is a practical way to find where to improve. Yang describes it as a useful lens, not an official industry taxonomy; the layers can overlap.
What the four layers mean
Yang illustrates the layers with an AI system that reviews a pull request. The same task can begin as a single request and grow into a bounded review-fix-test process. Each layer addresses a different kind of engineering problem.
| Layer | What changes | Code-review example | Typical failure it addresses |
|---|---|---|---|
| Prompt | The direct request to the model | Ask it to prioritize bugs, then security and performance issues; skip style nitpicks; provide line numbers and suggested fixes. | The model misunderstands what to inspect or how to prioritize its response. |
| Context | The information available beyond the request | Provide project conventions, relevant code, examples, and reference material. | The answer lacks project-specific knowledge because the model was not given it. |
| Harness | The software around one model interaction | Assemble inputs, connect tools, require structured output, validate it, retry failures, and check that cited files and lines are in the changed diff. | The response is malformed or makes claims that can be checked mechanically but are false. |
| Loop | The task-level process repeated toward a goal | Review, apply fixes, run tests, revert a failing fix commit, and stop at a defined limit or success condition. | A person must repeatedly start and evaluate the next step of a multi-stage task. |
These are lenses for locating work, not a requirement to build four separate components. Context sources, tool wiring, and permission controls can cross boundaries. Yang puts connecting tools and managing their calls closer to the harness, while acknowledging that the distinction can blur.
Free tools Windows power users keep installed
One-click scans. No signup required.
How to diagnose what needs improvement
Start with the failure you can observe, rather than adding more instructions by default:
#1 Best Overall
- The request is misunderstood: revise the prompt so the task, priorities, exclusions, and expected response are explicit.
- The answer sounds plausible but misses project facts: improve context by supplying or retrieving the conventions, code, examples, or references the model needs. Prompt wording cannot supply information the model has never received.
- The result is invalid or contains checkable false claims: add harness validation. For example, check output structure and confirm that a cited file and line belong to the pull request diff.
- The task needs repeated action and evaluation: consider an outer loop with state, feedback, progress checks, and explicit stop or escalation conditions.
The layers are not exclusive diagnoses. A workflow might need clearer instructions and better context, while its harness handles output validation. The point is to match the intervention to the failure rather than expect prompt changes to solve every reliability problem.
Harness retry and task loop are different
A harness retry concerns one model interaction: if a response is malformed or fails a validation check, the surrounding software can retry that call or fail visibly. A loop repeats the broader task toward an outcome, carrying state and feedback between iterations. Retrying a response does not, by itself, review a fix or establish that the pull request is ready.
Rank #2
In Yang’s illustrative code-review progression, the outer process reviews changes, applies fixes, and runs tests. It checks the baseline tests before attributing later failures to an AI-generated fix, reverts the specific failing fix commit, and stops after a maximum number of iterations or when its success condition is met. Unresolved cases can be escalated to a person, who retains final pull-request approval.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →What the code-review progression does—and does not—show
The example makes the layers concrete: first ask for a review of a diff, then supply project-specific context, then wrap the interaction in structured output and checks, and finally automate a bounded review-fix-test cycle. Its pseudocode is illustrative, not a tested implementation or evidence that automated code review is reliably safe.
Rank #3
The operational safeguards matter as much as the sequence: establish the test baseline, carry relevant feedback between iterations, set a success condition and iteration limit, and define when to stop or involve a person. A loop is only one part of an agent-like system; tool use, state management, and permission control also matter.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What evidence supports the framework
Yang presents a conceptual framework and illustrative pseudocode, not a measured study showing that these four layers improve a particular outcome. Treat the framework as a practical diagnostic aid, not as an empirical guarantee or settled industry standard.
Quick Recap
Rank #4
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
