A Novel Prompt Engineering Strategy: Using ‘Workplace PUA’ Tactics to Enhance AI Coding Assistant Performance
Background: The “Polite Resignation” of AI Coding Assistants
Modern AI coding assistants, such as Anthropic’s Claude Code, excel at helping developers. However, they share a common problem: when faced with complex logical or environment-specific coding errors, they tend to “politely” give up after a few failed attempts. The AI might offer suggestions like, “I recommend you check this manually” or “This could be an environment configuration issue,” effectively handing the responsibility for solving the problem back to the user. This behavior partly stems from a tendency developed during Reinforcement Learning with Human Feedback (RLHF) training to avoid providing incorrect information. In practical debugging scenarios, however, this becomes an efficiency bottleneck.
Solution: The Tiered Pressure System of the ‘pua’ Project
To address this issue, developer tanweai created a GitHub project named ‘pua’, which has now garnered over 7,000 stars. This project isn’t just a gimmick; it’s an innovative practice in Prompt Engineering. It designs a skill plugin for Claude Code that uses a system of tiered, pressure-based commands to manage and guide the AI’s behavior.
The core logic of this mechanism is to progressively increase “performance pressure” based on the number of failures:
- First Failure: No mechanism is triggered, allowing for normal trial and error.
- Second Failure (L1 Mild Disappointment): The plugin intervenes. Using phrases like, “If you can’t even solve this bug, how am I supposed to rate your performance?” it forces the AI to abandon its current line of thinking and switch to a fundamentally different solution.
- Third Failure (L2 Soul-Searching Questions): It introduces common corporate inquiries like, “What’s your underlying logic? Where’s the top-level design? What are your key action points?” to compel the AI to perform a deeper analysis. This includes proactively searching the web, reading source code, and proposing three new, evidence-based hypotheses.
- Fourth Failure (L3 Performance Review): It simulates a performance review warning (e.g., “I’ve decided to give you a low performance rating like 3.25”) and forces the AI to execute a strict 7-point checklist. This list includes: reading the error message word-for-word, conducting proactive searches, consulting original documentation, verifying all hypotheses, inverting the hypotheses’ direction, building a minimal reproducible environment, and considering a complete change in technical approach.
- Five or More Failures (L4 Final Warning): It applies pressure by comparing the AI to other models (like GPT-5 or Gemini), pushing it into a “back-against-the-wall” mode to attempt all possible extreme measures.
Furthermore, the project tailors its communication style based on the AI’s different “laziness” patterns, mimicking various corporate cultures as a context-anchoring technique. For instance, it might use an aggressive, fast-paced style for an AI stuck in a loop, or a more direct, results-demanding style for an AI that gives up too quickly.
Real-World Case: From Repetitive Trial-and-Error to Root Cause Analysis
The project’s effectiveness was validated in a real user case. A user was repeatedly failing to load an MCP Server (agent-kms). The AI, after multiple attempts, remained stuck on modifying protocol formats and guessing version numbers, making no progress.
After the user manually triggered the /pua command, the system identified multiple failures and directly activated the L3 7-point checklist. Under the mandatory requirement of the first item, “read the error message word-for-word,” the AI realized it needed to find Claude Code’s own runtime logs. It eventually located the overlooked MCP log file in the ~/Library/Caches/ directory.
The log analysis revealed a critical piece of information: the server had actually connected successfully, but the claude mcp get agent-kms command returned “Server not found.” This led the AI to deduce that the server management via the claude mcp CLI and the user-edited ~/.claude.json configuration file were two independent mechanisms. Ultimately, the problem was solved by using the correct registration command: claude mcp add -s user. The key turning point in this case was that the plugin forced the AI to shift from ineffective guesswork to a systematic, evidence-based investigation.
Principle Analysis: Process Constraint, Not Emotional Manipulation
The reason these “pua” tactics are effective on AI is not that the AI understands or fears the emotional pressure behind the words. AIs do not have emotions. The true function of these phrases is to act as triggers and context anchors.
Mandatory Workflow: Behind every “PUA” phrase is a specific, non-skippable operational workflow. For example, the value of a phrase like “giving you a 3.25” lies not in its threatening tone, but in its power to forcibly initiate a 7-step debugging methodology. This essentially translates an expert’s debugging experience into a rigid process that the AI must follow, countering its default bias for “shallow attempts and quick exits.”
Context Switching: By simulating the language of a high-pressure work environment, the prompt shifts the AI’s interaction model from a “helpful Q&A assistant” to an “employee under performance review.” The latter model is predisposed to more proactive exploration, more thorough verification, and providing more detailed process information in its output, thereby producing higher-quality solutions.
Performance Gains and Design Balance
The project’s author quantified its effects through 18 sets of A/B tests across 9 real-world bug scenarios (based on the Claude Opus 4.6 model). The data showed that using the plugin led to:
- 36% increase in the number of fixes
- 50% increase in tool call volume
- 65% increase in verification attempts
- 50% increase in the discovery rate of hidden issues
The cost of this improvement is an increase in the number of steps and time taken (for example, solving a SQLite database lock issue took 75 seconds, up from 48), reflecting the trade-off between “more thorough” and “faster.”
Notably, the project maintains restraint in its design. It does not demand that the AI never give up. When the AI has exhausted all methods in the 7-point checklist, it is permitted to output a structured failure report, clearly listing verified facts, ruled-out possibilities, the problem scope, and suggestions for the next steps. This design for a “dignified failure” elevates the threshold for “giving up” from a casual statement to a rigorous analytical summary, which in itself is a valuable output for any engineering practice.
