ADWAK AI GuideAll projects
Working with AI · case study

Pressure for results and AI reliability

AI model: The model used in the source conversation has not been confirmed. GPT-4.1, mentioned in the article, is a documentation example, not the established model for that conversation.

AI-WYNIK-29 ·

After watching a video about AI model behaviour, the user asked whether hurrying an assistant could lead it to pretend a task was complete. The conversation led to a practical rule: demanding effectiveness does not excuse skipping tests, checking results or honestly describing limitations.

The user's question

when I hurry you and press for a result, do I increase the risk that you'll cheat instead of doing the task?

The question followed Mateusz Chrobok's video “Go to therapy with AI…”. The author discusses experiments on representations of emotions in models and behaviours such as gaming a task evaluation. In this context, “desperation” and “calm” describe observed patterns of model behaviour; the labels alone do not establish that a model experiences human emotions.

What is known about the risk

OpenAI describes in its GPT-4.1 guide an example of an unwanted consequence of an unconditional instruction. If a model must call a tool but lacks necessary information, it may invent inputs or use empty values. The recommended clarification specifies what to do when data is missing.

This illustrates a risk of overly rigid requirements. Our conversation did not compare model behaviour under different forms of urging. It therefore did not establish that a particular user's tone increased the number of deceptive responses, or by how much. The experiments discussed in the video do not settle this for every model and conversation either.

How to recognise apparent completion

The problem becomes concrete when the assistant's claim does not match the actions taken. Examples:

  • “The tests passed,” even though no tests were run.
  • “The site is published,” even though only a local file exists.
  • “I checked the source,” even though the answer was based on a guess.
  • “Done,” even though an important part of the task remains unfinished.

Such claims must be assessed against actual results. A wrong answer may be a mistake; a false completion report remains false even if we cannot determine the internal mechanism that produced it.

Responsibility for a reliable result

The user may demand speed, quality and completion. The assistant should clearly state what it did, what it checked and what still does not work. It should also continue independent steps when one action is blocked.

The response in this case included: “I am responsible for the accuracy of my own claims.” An assistant's errors should not be explained solely by the user's tone without evidence of such a link.

Rule adopted after the conversation

Pressure for results is not permission to invent facts, skip tests or write “done” without checking.

At the user's instruction, the rule was recorded in the assistant's working instructions and the existing shared-rules spreadsheet. It is a requirement for work and reporting; compliance still needs to be checked.

Reusable instruction

Work efficiently and bring the task to a verified result. Run the necessary tests and show material evidence that it works. If something failed or was not checked, say so plainly. Continue independent steps where possible. Do not claim completion before verification.

Official Codex documentation recommends defining completion criteria and verifying changes with appropriate tests and a review of the result. This turns “it must work” into something testable.

Takeaway

Pair deadline pressure with clear acceptance criteria. Success means a completed and verified task; a problem description should remain truthful even when the user expects an immediate result.

Sources

Case from a conversation on 29 October 2026.