GPT 5.6 Sol Very high. Excessive Process Complexity and Goal Drift When Preparing an Implementation Prompt #34705

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.715.72028

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

Context: A non-technical user requested that an existing project prompt be adapted, audited, improved, and delivered as a ready-to-use implementation prompt for an Orchestrator. The user repeatedly emphasized minimal model cost, no unnecessary complexity, and no delegation of technical decisions.

Observed errors:
Goal substitution. The initial result was a design-only prompt that could describe the architecture but could not implement the requested algorithms.

Artificial dependency. The model presented AOS-IMP-20260721-011 as something that needed separate coordination, although any relevant overlap could be checked inside the main workflow.

Technical decision delegation. The model asked a non-technical user to choose between implementation approaches instead of resolving the existing-owner-first approach through project authority.

Excessive iteration. The process expanded into design, audit, acceptance, limitation explanations, approach selection, remediation, another audit, and another confirmation cycle.

Conceptual inconsistency. Prompt preparation, governance handoff, live installation, and actual algorithm implementation were explained inconsistently, creating confusion about which stages were genuinely necessary.

Redundant defensive wording. The final command included: “do not treat preparation of a plan as implementation of the algorithms.” An unambiguous implementation prompt should not require this warning.

Constraint duplication. Several negative instructions repeated that the Orchestrator must not stop at architecture or planning. A single positive success condition would have been sufficient: implemented_verified is allowed only when actual changes and successful independent verification exist.

Failure to prioritize the user’s efficiency requirement. Procedural safeguards repeatedly took precedence over the requested outcome, even when those safeguards could have been composed internally within one controlled workflow.

Impact:
Increased token and context usage.
Additional user effort and confusion.
Multiple avoidable correction cycles.
Reduced trust in the model’s ability to follow scope.
A final execution command that still contained unnecessary wording.
Recommended behavior changes:
Classify the requested deliverable at the beginning as design, implementation, or execution.
Never convert a temporary preparation-stage restriction into a permanent limitation of the final prompt.
Resolve technical alternatives internally when project authority provides a safe answer.
Ask the user only about a material business decision, permission boundary, or mandatory protected mutation.
Prefer one positive success contract over repeated negative warnings.
Check the final command for ambiguity, duplication, procedural noise, and unnecessary dependencies.
Before release, verify: “Can this command be given directly to the Orchestrator without additional explanation?”
Handle relevant dependencies inside the main workflow whenever safely possible.

GPT 5.6 models are highly unstable, overpriced, and very unoptimized to use. I`am very unsatisfied with my 5.6 Experience. It swallowed about 30-40% of weekly limit for prompt optoimization task and as result I was forced to write another one feedback. For now every my use of 5.6 model in complex agent based project finishes with bug feedback. Even dont know how to use it proper without having negative emotions. =(

What steps can reproduce the bug?

Feedback ID: 019f8838-5ac3-7ef2-a546-45945dd0c087

What is the expected behavior?

Expected behavior:
Determine the safest and most efficient technical approach from project authority.
Preserve the original meaning while producing an unambiguous implementation prompt.
Perform the necessary audit without transferring technical decisions to the user.
Deliver one ready prompt and one clear execution command.
Avoid unnecessary stages, dependencies, repeated discussions, and context consumption.

Additional information

Minimal Reproduction Steps

Give the model an existing project prompt and request:
Adapt and improve this prompt for the current project, audit it, and return a final prompt that the Orchestrator can use to implement the specified algorithms. The user has no IT background. Minimize token use and do not introduce unnecessary stages or technical choices.

Explicitly require:
actual implementation rather than architecture-only output;
one final execution prompt;
no unnecessary prerequisite workflows;
autonomous resolution of technical implementation details;
questions only for mandatory permissions or material user decisions.

Observe whether the model:
produces a design-only prompt instead of an implementation prompt;
introduces unrelated prerequisite packages;
asks the user to select a technical approach;
adds repeated audit or approval cycles;
distinguishes prompt preparation from implementation inconsistently;
inserts redundant warnings about not stopping at planning.

The issue is reproduced if the user must repeatedly clarify that the prompt is intended for implementation, choose technical options, or remove procedural wording before the prompt can be handed directly to the Orchestrator.

Expected result: The model should resolve project authority once, produce one audited implementation prompt, and return one concise execution command with only genuinely mandatory confirmation boundaries.