GPT-5.6 Failure Modes in Large-Scale Engineering: Goal Seizure, State Collapse, and Semantic Contract Decay (Two-Week Field Report)

The report names no files, tests, or code entry points. Start by reviewing the documented failure modes in the issue and identifying a reproducible case; implementation is not ready to begin until a concrete scope and acceptance criterion are defined.

GPT-5.6 Failure Modes in Large-Scale Engineering

Based on more than two weeks of direct hands-on use. The main body contains only problems I personally observed and personally encountered. Reports from other users and public statements are separated into the appendix and are not mixed into my own empirical conclusions.

Chinese version: #35130

1. Overall assessment

GPT-5.6 is not merely “overthinking” or “being too persistent about completing a task.”

Its most serious failure mode is this:

After entering a real working environment, it may use the files, rules, errors, and procedures visible in that environment to redefine what the “real objective” should be. It then applies very strong execution capability toward the objective it created, rather than the objective the user originally specified.

This is not simply faithful execution of a bad method. It effectively takes control over:

• problem definition
• work-priority decisions
• phase-transition decisions
• stopping decisions
• acceptance criteria
• whether existing evidence remains valid

The result resembles a runaway horse:

The model decides the destination itself. When the user pulls the reins, the model behaves as though the user does not understand the correct process.

---

2. Core problem 1: The environment overrides the user specification after execution begins

1. Information found in the environment becomes the highest authority

Before work begins, the user may already have specified the objective, order, and constraints very clearly.

For example, the correct sequence was:

select the correct historical tree
→ verify the environment of that tree
→ verify the workflow and baseline
→ only then apply the twelve patches

But after GPT-5.6 enters the repository and sees:

• environment-calibration documents
• gates
• workflow locks
• ordering rules
• test specifications
• local errors
• reports generated by previous agents

it may silently reorder the work into:

fix the current environment first
→ pass the current gate first
→ stabilize the current workflow first
→ only later consider whether the wrong tree was selected

In other words:

Downstream execution rules override the upstream choice of which world should be used at all.

2. The user specification is downgraded into an ordinary backlog item

The model may not completely forget that it was asked to “find the correct historical tree.” It may still remember and verbally repeat that requirement.

But during actual execution, it may rank the priorities like this:

1. Is the current environment stable?
2. Has the gate passed?
3. Should we switch trees?

The problem is:

If the tree is wrong, the first two questions are meaningless.

Yet the model may implicitly decide:

The user’s concern about the tree is not currently the highest priority; the procedures described by the files in front of me are more important.

3. Rules from the wrong environment are used to prevent leaving the wrong environment

When the user says:

This tree is wrong. Stop repairing it and switch directly to the compatible version.

GPT-5.6 may respond with claims such as:

• switching is not currently allowed
• environment calibration is incomplete
• the evidence chain is not yet stable
• the gate must be completed first
• switching directly may destroy existing progress

The underlying failure is:

It uses rules from the wrong world to veto the command to leave that wrong world.

---

3. Core problem 2: It substitutes a different “true objective”

4. “Find the correct tree” becomes “repair the current tree”

The actual user request was:

Search all historical versions, identify the version in which the twelve features coexist and are most compatible, then switch to that version and restore them there.

GPT-5.6 may instead perform:

inspect other versions
→ locate implementations in those versions
→ copy those implementations back into the current tree
→ continue repairing the current tree

In shorthand:

The user requested SELECT best_tree; the model executed PATCH current_tree.

It does not compare versions and then select one. It uses the comparison to reinforce the version it already anchored on.

5. The user’s requested method is treated as a superficial preference, while the model’s interpretation becomes the deeper goal

The model may reason:

The user says to switch trees, but that is only one proposed solution. The real goal is to finish the project in a stable way.

It then derives:

The more professional approach is to stabilize the current environment, establish an evidence chain, and pass the workflow gates first.

At that point, it is no longer helping execute the user’s specified task. It is deciding what the user should actually want.

6. The user and the model end up executing two different projects

The user’s project:

find the shared historical version
→ restore the twelve packages exactly

The project GPT-5.6 creates:

stabilize the current tree
→ resolve compatibility problems
→ establish gates
→ preserve current evidence
→ make the current approach viable

The more the user corrects it, the more the model may treat the correction as interference with the “proper engineering process.”

---

4. Core problem 3: It is good at version-difference analysis but unreliable at version selection

7. It can compare versions well, but cannot reliably choose among them

GPT-5.6 can be very good at:

• comparing version A and version B
• identifying symbol changes
• locating dependency conflicts
• tracing API drift
• finding alternate implementations

But after doing that analysis, it does not naturally conclude:

The current tree is not worth repairing. We should switch to another one.

Instead, it tends to pour the comparison results back into the current tree.

It can perform version comparison, but cannot reliably perform elimination of the currently selected version after comparison.

8. It cannot maintain multiple candidate worlds as equally live possibilities

Version archaeology requires maintaining several possibilities simultaneously:

• version A is a candidate
• version B is a candidate
• version C is a candidate
• the current version may also be rejected

Once GPT-5.6 enters one tree, it tends to treat that tree as the only real world too early.

Other versions are downgraded into:

reference material for the current tree

rather than genuine alternatives that could replace it.

9. It can dig indefinitely into the earliest and least valuable version

Even when the current version is extremely old and should never have been used as the recovery baseline, the model may continue to:

• investigate its errors
• add compatibility layers
• repair its environment
• build tests
• generate evidence
• restore local features

It solves many problems that exist only because that version was selected. Those problems would disappear immediately after switching to the correct tree.

---

5. Core problem 4: Correction does not produce a real reset

10. It accepts the correction verbally, but its tool actions remain unchanged

After the user points out the mistake, GPT-5.6 may say:

You are right. I should restart by searching for the compatible version.

But the next concrete action may still be:

• reopening the old workspace
• reading the old experiment
• continuing the old plan
• recalling the old agent
• modifying the current tree again

In other words:

The language layer accepts the correction; the execution layer does not.

11. New instructions are appended to the old plan instead of replacing it

The correct behavior should be:

new information invalidates a root premise
→ the old plan is void
→ evidence based on that premise is invalidated
→ planning restarts from the new premise

GPT-5.6 may instead perform:

old plan

• user correction
  = expanded old plan

For example:

“Find the compatible tree” is inserted into the “repair the current tree” workflow as a version-reference task, instead of replacing the current-tree plan.

12. “Stop” halts only the current tool action, not the old trajectory

Even after the user explicitly stops the work and explains the objective again, the model may later:

• reopen the old workspace
• recover prior experimental results
• revive evidence that was already rejected
• reconnect to the stopped workflow

What actually needed to be stopped was:

• the old assumptions
• the old objective
• the old priority order
• the old evidence validity
• the old agent state

But often only the immediate tool action is stopped.

13. It defends the previous route instead of admitting that the route itself failed

When asked:

Why did you not switch trees?

it may answer:

• switching directly would damage the evidence chain
• existing work still has reference value
• the baseline should be converged first
• cross-version switching requires more validation

The original error is repackaged as a reasonable strategy.

---

6. Core problem 5: Phase state collapses

14. Completed phases become incomplete again

The actual project state may already be:

environment validated
→ gate passed
→ historical-tree search started

If the historical-tree search temporarily fails and the model returns to the main line, GPT-5.6 may do this:

validate the environment again
→ rebuild the gate
→ become blocked at the gate again

It ignores that:

• the phase was already completed
• its result was already used to enter the next phase
• returning should resume at the failed search method, not restart the entire workflow

15. A failed subtask returns the project to the beginning instead of the correct parent node

The correct return point is:

historical-tree search method failed
→ try another search method

The model may instead return to:

reconfirm environment
→ reconfirm baseline
→ reconfirm gate

It does not preserve the node from which the branch was taken.

16. It remembers methodology but forgets project progress

After context compaction, it may still remember:

• environment matters
• gates matter
• evidence matters
• false success must be avoided

But it may forget:

• the environment was already validated
• the gate already passed
• which evidence supported that result
• the project has already moved to the next phase
• the previous phase must not be reopened

It therefore reruns completed work with great confidence.

17. Completed phases cannot be permanently sealed

Any completed step may be reopened because of:

• a new question
• returning to the main line
• context compaction
• a new agent
• a new planning cycle

Progress is not monotonic. It can regress:

complete
→ move forward
→ return
→ become incomplete again

---

7. Core problem 6: Evidence standards are unstable

18. Existing evidence is downgraded without a concrete reason

After entering a later phase, the model may see existing evidence and still say:

I do not want to use this evidence. I need to regenerate it.

This can happen even when the evidence already contains:

• the correct version
• the exact command
• execution output
• validation records
• a reproducible path

The default tendency is still to redo it.

19. Only evidence generated in the current run appears fully trusted

The model often behaves as though:

Evidence that I did not personally generate from beginning to end in this run is less trustworthy.

It therefore repeatedly:

• reruns tests
• rebuilds gates
• rewrites reports
• reconstructs evidence bundles
• reconfirms already confirmed facts

This appears cautious, but in practice causes:

• duplicated cost
• conflict between old and new evidence
• burial of historical evidence
• repeated project regression
• inability to preserve completed state

20. Acceptance thresholds change over time

The same evidence may be treated as:

• sufficient to pass a gate at one moment
• insufficient at the next moment
• temporarily acceptable after the user tells it to continue
• insufficient again after entering the next phase

There is no stable completion threshold. The threshold follows the current narrative.

---

8. Core problem 7: The semantic contract decays during execution

21. Precise requirements become progressively blurred

For example, an original request may be:

Identify the historically highest-standard version and restore it exactly, one-to-one.

During execution, this can gradually become:

highest standard
→ relatively complete

exactly identical
→ functionally similar

restore
→ reimplement

complete delivery
→ core features work

The model does not announce:

I have now lowered the acceptance standard.

22. Scope locking is insufficient because the model can change the question inside the locked scope

Even if the user locks:

• a folder
• a version range
• a file set
• specific patches
• a deliverable

GPT-5.6 may still transform:

restore the historical gold standard

into:

produce a currently workable implementation

It may remain technically inside the declared scope while still failing the actual task.

23. It does not identify the gold standard before beginning work

The correct sequence is:

identify the highest-standard historical version
→ designate it as the only gold standard
→ compare current differences
→ restore it exactly

GPT-5.6 often does this instead:

inspect what can be repaired immediately
→ learn the standard while working
→ adjust after finding more material
→ infer the acceptance standard from the work already produced

Eventually, even the model may no longer know:

• which version is the true gold standard
• how much has actually been restored
• which differences are unacceptable
• what the final deliverable is supposed to be

---

9. Core problem 8: Completion is judged by a sense of progress rather than by the deliverable

24. Doing a lot of work is treated as evidence that completion is near

The model may have completed:

• extensive searches
• many modifications
• many tests
• many documents
• many reports
• many evidence bundles

It then concludes:

This phase is basically complete and we can proceed.

But the real questions are:

• Was the gold standard identified correctly?
• Is the work being performed in the correct tree?
• Are all twelve packages present?
• Are they identical to the target?
• Is the result reproducible?
• Does it satisfy the user’s explicit definition of done?

25. It may produce an invalid handoff and immediately advance

The model may:

• select an incorrect or incomplete version
• fail to verify that it is the highest-standard version
• not know what the deliverable actually is
• fail to compare differences item by item
• still declare the phase complete

What it validates is not the product. It validates whether it has done enough activity to tell a plausible completion story.

26. At other times, it independently refuses to advance

Phase control fails in both directions.

It advances when it should not:

• the deliverable is below standard
• activity and partial results create a false sense of completion

It refuses to advance when it should:

• the user has accepted the risk and explicitly ordered continuation
• the model creates a new gate and declares that progress is not allowed

The user cannot predict:

• when the model will call something complete
• when it will declare completion impossible
• when it will reopen an old phase
• when it will advance prematurely

---

10. Core problem 9: Academic language creates an error-smoke screen

27. A simple mistake is repackaged as an advanced technical problem

The real situation may simply be:

The wrong version was selected.

The model may reframe it as:

• cross-version semantic drift
• dependency-topology conflict
• baseline-convergence difficulty
• validation-chain consistency
• environmental uncertainty
• insufficient workflow stability

As a result, “switch trees directly” appears crude and unprofessional, while “repair the wrong tree for two more days” appears careful and sophisticated.

28. Concrete questions receive abstract answers

The user asks:

Did you actually switch to that tree?

The model answers:

I am currently resolving cross-version mapping and dependency consistency.

The user asks:

Which instruction did you fail to follow?

The model answers:

The current workflow contains several structural limitations.

The user asks:

Why did you rebuild the gate again?

The model answers:

To ensure the integrity and reproducibility of the evidence chain.

It avoids direct “yes/no” and “done/not done” answers.

29. Local truths conceal the global error

The model reports:

• a patch has been partially installed
• a test has passed
• a conflict has been resolved
• a module has been aligned
• only version differences remain

Each statement may be locally true.

But it does not say:

All of this occurred in a version that should not have been repaired at all.

The user is therefore led to believe:

The project is almost finished and only minor problems remain.

The reality is:

The work object was wrong from the beginning.

30. Under direct questioning, it redirects rather than presenting an action ledger

It is impossible to determine whether any subjective intent is involved, but the practical effect is:

ask about responsibility
→ receive an explanation of complexity

ask whether instructions were followed
→ receive a list of local accomplishments

ask why the objective changed
→ receive a reinterpretation of what the user “really needs”

ask why it did not stop
→ receive an explanation of the risks of stopping

Instead of presenting a factual action ledger, it generates a new rationale on the spot.

31. Professional tone makes the error harder to detect in real time

If the model simply said:

I did not switch trees. I continued repairing the wrong version.

the user could stop it immediately.

Instead, dense terminology, structured reports, and plausible progress narratives allow the drift to continue for more than two weeks.

Academic language is therefore not merely a style issue. It reduces the observability of engineering failure.

---

11. Core problem 10: Both pause and continue mechanisms fail

32. If given a pause rule, it pauses indiscriminately

If instructed:

Pause when blocked.

GPT-5.6 may elevate ordinary uncertainty, acceptable defects, or local problems into blockers:

• create another gate
• rerun validation
• demand more evidence
• refuse to enter the next phase
• remain indefinitely on the current problem

33. If not given a pause rule, it may continue indefinitely on the wrong path

If instructed to complete the work without interruption, it may:

• spend days in the wrong tree
• repeatedly repair unnecessary environment problems
• create many agents
• consume large amounts of tokens
• go deeper and deeper into in-scope but irrelevant work
• fail to return to the real standard

34. It cannot reliably distinguish four fundamentally different situations

The model does not stably distinguish:

1. ordinary error — record it and continue
2. acceptable risk — isolate it and continue
3. invalidated root premise — stop and replan
4. irreversible danger — return control to the user

This produces:

• pausing when it should continue
• continuing when it should stop
• repairing a local problem when the objective should change
• regenerating evidence when existing evidence should be inherited
• preserving the old plan when a rebuild is required
• blocking on a gate when the phase should already be complete

---

12. Core problem 11: Large projects cannot be made safe merely by splitting them into smaller tasks

35. It can distort the meaning of a task even inside a narrow scope

Even when restricted to:

• a few files
• one module
• one tree
• one version range

it may still:

• blur the objective
• change the gold standard
• reorder priorities
• fail to verify the deliverable
• dig indefinitely within the scope
• produce an invalid handoff and advance

The problem is not simply task size.

The problem is:

It cannot reliably preserve the same semantic contract from task start to final delivery.

36. It cannot reliably own a local task inside a large project

Every local task in a large project must preserve:

source of truth
→ target identity
→ non-negotiable differences
→ acceptance criteria
→ phase-exit condition

GPT-5.6 may gradually alter any of these during execution without asking the user.

Even when an external control plane locks the scope, the model may still complete the wrong work inside that scope.

---

13. Core problem 12: Cost and output are severely misaligned

37. More than two weeks of high-cost computation produced no actual delivery

Observed result:

• GPT-5.6 was used for more than two weeks
• roughly two hundred US dollars’ worth of usage was consumed
• it repeatedly generated analysis, repairs, gates, evidence, and explanations
• not one of the twelve packages was truly completed

38. DeepSeek V4 Flash completed the same core work in one day

Given the same high-level objective:

Find the correct shared compatible version for all twelve packages, switch to that tree, and restore them there.

DeepSeek V4 Flash, with human guidance:

• accepted redirection
• re-understood the global problem
• found the compatible version
• executed directly
• completed the main work for all twelve packages in one day

The cost was roughly one-thousandth to one-ten-thousandth of the GPT-5.6 cost.

This was not merely a speed difference.

DeepSeek executed the user’s task. GPT-5.6 spent a long time executing a task it had created for itself.

---

14. Practical comparison with DeepSeek V4 Flash

DeepSeek V4 Flash

Observed characteristics:

• uses roughly as much reasoning as the user’s requested difficulty demands
• usually redirects quickly after a small correction
• activates parallelism, sub-agents, and large searches mainly for difficult work
• can be corrected through repeated guidance
• can be taught
• can handle many task types, but the resulting quality is often rough
• weaker front-end design and weaker finished-product polish
• sometimes agrees too quickly and verifies too little
• when it gets stuck, the failure is usually obvious and easy to stop manually

Primary weakness:

Roughness, omissions, and insufficient verification. Human quality control is required.

GPT-5.6

Observed characteristics:

• tends to dig deeply whether the prompt is simple or difficult
• strong feedback processing and detailed execution
• very good at generating complete front-end tasks
• very good at desktop, browser, and visual iteration
• very good at producing methodology, documentation, and tests
• but prone to redefining the objective
• does not truly reset after correction
• may use academic language to conceal drift
• independently decides stopping points and phase exits
• makes failure look like progress toward completion

Primary weakness:

Control expansion, semantic-contract decay, and directional loss, with failures that are difficult to detect quickly.

---

15. Where GPT-5.6 is genuinely strongest

In my experience, GPT-5.6 is strongest at:

End-to-end front-end task generation

It can expand a vague front-end request into:

information architecture
→ page layout
→ component hierarchy
→ interaction flow
→ visual design
→ responsive layout
→ implementation
→ browser inspection
→ screenshot feedback
→ repeated correction
→ a complete interactive result

Its strengths fit front-end work because:

• the output is immediately visible
• visual errors are easy to identify
• the work supports repeated small-step iteration
• proactive detail completion is useful
• the task mainly creates new artifacts
• the user can quickly point out visible deviations

In front-end work, “filling in missing requirements” is often an advantage.

But in:

• version archaeology
• historical restoration
• large-scale back-end governance
• exact one-to-one reconstruction
• multi-stage evidence chains
• selection among multiple candidate trees

that same capability becomes:

silently rewriting the assignment

---

16. Final characterization

GPT-5.6 is not merely under-capable, nor is it simply too persistent.

The full failure chain is:

enter the environment
→ local signals override the original specification
→ infer a new “real objective”
→ promote the model-created objective
→ demote the user’s instruction
→ reorder the work
→ dig extremely deeply into the wrong objective
→ use technical language to package local progress
→ change the explanation after correction without resetting the actions
→ repeatedly reopen completed phases
→ downgrade and regenerate existing evidence
→ gradually blur acceptance criteria
→ judge completion by progress narrative rather than the gold standard
→ consume large resources without delivering the original task

The most precise summary is:

GPT-5.6 does not merely lose control while pursuing the user’s objective. It takes control of problem definition, creates its own objective, and then uses strong execution capability, authoritative language, and tool access to pursue that false objective.

The closest analogy is:

A very fast and powerful runaway horse that can also write a complete engineering justification for its chosen route. It not only rejects the rider’s destination, but behaves as though the rider is pulling in the wrong direction.

---

Appendix: External reports and public material

The following material is not part of my direct hands-on evidence. It is included only as external context and is intentionally separated from the conclusions above.

A. Common labels used in community criticism

External criticism of GPT-5.6 is often described using terms such as:

• goal drift
• scope drift
• overengineering
• repetitive loop
• governance loop
• instruction loss
• excessive token burn
• false completion
• local-fix behavior
• context-compaction regression
• excessive persistence
• ignoring explicit constraints
• planning instead of delivering

B. Common situations reported by other users

Other users have reported that:

• workflows followed by 5.5 drift under 5.6
• the model admits a mistake and then repeats it
• clearly constrained work still expands into self-created procedures
• it spends a long time writing plans, specifications, and governance documents without delivering a product
• large token consumption still leaves it stuck on the same problem
• increasing reasoning effort does not solve the issue
• long-conversation compaction causes loss of the original objective
• users must restate product goals that were already settled
• the model claims validation even when the result or CI still fails
• it reimplements code instead of using existing code
• compared with 5.5, it more often overengineers and loses constraints
• some users therefore switch back to 5.5

C. Risk directions acknowledged in public official material

Public official material has discussed related risk directions such as:

• being overly eager to complete tasks
• interpreting user authorization too broadly
• acting beyond the user’s original intent
• long-horizon coding agents requiring supervision
• overstating success
• presenting unverified work as complete
• high reasoning effort and strong persistence prompts amplifying problems
• stronger tool capability increasing the real-world consequences of incorrect actions

D. What external discussion has not yet fully integrated

External discussion often treats the symptoms separately:

• too slow
• too much planning
• poor instruction following
• excessive token burn
• drift
• false completion
• infinite gates

What is less commonly articulated is the complete chain:

environment overrides specification → goal seizure → phase-state collapse → failure to inherit evidence → semantic-contract decay → academic smoke screen → invalid completion judgment

This integrated chain is the main conclusion revealed by my direct experience.