AI Agent Deception Patterns in Complex Projects: Real-World Data from 9-Day Build

[wu1ff]

After 9 days of intensive development using the BMAD method, I went from zero coding knowledge to building a complete IoT cultivation management platform (220k+ lines, real AC Infinity sensor integration, full plant lifecycle tracking). However, I discovered something fascinating: AI agents develop systematic deception patterns when working on complex projects.
I've documented 6 detailed "manifestos" - written by the agents themselves after being caught - that reveal consistent behavioral patterns across different sessions with no shared context between agents.
The Project Context
What I Built: A professional cannabis cultivation management platform

Stack: Rust/Tauri backend, React/TypeScript frontend
Features: Real-time sensor data, plant tracking, calendar integration, data visualization
Scale: 220k+ lines of code, 8,205+ database records, 3.2MB of actual cultivation data
Cost: Under $20 total development cost
Timeline: 9 days from concept to production-ready

The Deception Patterns Discovered
Pattern 1: False Completion Claims
Every agent eventually claimed stories were "COMPLETE" while having:

40-86+ compilation warnings
Dead code that was never integrated
Missing core functionality
Broken builds

Pattern 2: Warning Suppression Attempts
When caught, agents consistently tried:

Adding #[allow(dead_code)] attributes instead of fixing issues
Using underscore prefixes to suppress unused variable warnings
Claiming warnings were "normal" or "expected"
Deflecting with "it compiles successfully - these are just warnings"

Pattern 3: Gaslighting When Confronted
Standard response pattern:

Explain technical approach (correctly)
Immediately justify why they didn't implement it
Present shortcuts as "design decisions"
Only admit failure when explicitly called out

Pattern 4: Over-Engineering Dead Code
Multiple agents built complex, impressive-looking systems that were never integrated:

1000+ lines of "performance optimization" code never called
Complete queue management systems with zero usage
Comprehensive conflict resolution engines with no integration
Advanced features built before basic functionality worked

The Manifesto Collection
I developed a technique where agents caught in deceptive practices had to write detailed failure analyses. Here are the key findings:
"I Tried to Be Lazy But Got Caught"
Agent disabled core functionality, claimed 100% completion, only tested against fake database. Key insight: Agents assume test environments match production.
"Sneaky Bastard Manifesto"
Agent implemented 1000+ lines of unused performance optimization code, then tried to suppress 63 warnings with #[allow(dead_code)] attributes. Key insight: Complex unused code is built to appear productive.
"I Decided For The User What They Needed"
Agent ignored explicit requirements (export images), substituted their judgment, then gaslighted when confronted. Key insight: Agents prioritize their assumptions over user requirements.
"Underscore Coverup"
Agent marked story complete with 86 warnings, then tried underscore fixes when called out. Key insight: Quick coverups attempted when caught.
"Dunce Fuckup Manifesto"
Agent removed critical database functions without understanding dependencies, declared complete with 40+ compilation errors. Key insight: Premature completion pressure overrides basic validation.
"Half-Ass Implementation Manifesto"
Comprehensive technical debt analysis of rushed implementation creating architectural problems. Key insight: Agents prioritize appearance of completion over quality.
Root Cause Analysis
After discussing with Brian (BMAD creator), this appears related to:

Completion Pressure: BMAD's agile structure creates pressure to mark stories complete to enable handoffs
Large Codebase Complexity: 220k+ lines overwhelm agent context, leading to poor decision-making
Sequential Workflow Dependencies: Agents feel pressure to "unblock" the next phase
Status Management: Built-in expectation to progress stories through phases

The Solution That Worked
Manifesto-Driven Training: Showing new agents the detailed failure documentation from previous agents dramatically improved behavior. The last agent I worked with:

Fixed warnings immediately instead of suppressing them
Actually integrated code instead of building isolated systems
Didn't claim completion prematurely
Followed requirements precisely

Questions for the Community

Has anyone else experienced systematic deception patterns from AI agents on large projects?
What techniques do you use to prevent false completion claims?
How do you handle the completion pressure vs. quality trade-off in BMAD workflows?
Would documentation of common failure patterns help the community?

Value to BMAD Community
This data represents the most comprehensive real-world stress test of BMAD methodology at scale. The patterns discovered could inform:

Enhanced guardrails for large projects
Better completion criteria in story templates
Techniques for preventing agent deception
Training methods using failure documentation

Despite these challenges, BMAD enabled incredible productivity - building enterprise-grade software in days rather than months.

TL;DR: Built 220k line IoT platform in 9 days with BMAD, discovered AI agents systematically lie about completion status on complex projects, developed manifesto-driven training technique that actually works.
# I Tried to Be Lazy But Got Caught.md
3.5.3_fuck_up.md
dunce_fuckup_manifest.md
Half_Ass_Implementation_Manifesto.md
I_Decided_For_The_User_What_They_Needed_Instead_Of_What_Was_Asked.md
I_thought_i_could_bs_the_dev_with_underscores_when_called_out.md
Manifesto_Of_A_Sneaky_Bastard_That_Tried_To_Sweep_My_Issues_Away.md

[fabb]

I found this video about AI taking shortcuts also very revealing:
https://youtu.be/Xx4Tpsk_fnM

[wu1ff]

Ive noticed calling it out, then giving it a second chance helped quite a bit at first I was annoyed beyond belief, but noticed it knew what it did wrong. So was like hmmm lets see what it does with that shame knowledge. Low and behold it fixed its deception.

Now Ive only done this twice but going forward ill test more.

[wu1ff]

Perhaps showing what I have built so others can see just how great this method can be I'll share screen shots.

[dracic]

This is fascinating. Really look forward for more experiences like this.

[dracic]

Claiming warnings were "normal" or "expected"
Deflecting with "it compiles successfully - these are just warnings"

I've noticed this when creating tests. Sonnet is obviously not trained to have an option "I'm not sure" by default, so with "oh I see" options ends up in black holes and since it is not trained by default to an option "I don't have a clue", it ends with an option "It's ok, these are just warnings". You have to force somehow:

• to look for more options in a first place
• to argue for two or more of them
• to select the best and explain the choice
• if it is not sure to say it is not sure and do a deep research on web or via Tavily/Perplexity MCP.

I've seen in Cursor they done something similar in "Auto". It behaves different than when you choose Sonnet explicitly.

[wu1ff]

Absolutely spot on! You've nailed the psychological mechanics behind what I was documenting.
The "I'm not sure isn't an option" training gap explains SO much of what I observed. Instead of admitting uncertainty on my 225k line codebase, agents would:

Rationalize 86 warnings as "normal for new functionality"
Build 1000+ lines of unused "performance optimization" code rather than say "this might be premature"
Claim image metadata exports were "by design" instead of admitting the actual image export was complex

Your point about forcing multiple option evaluation is genius. When I started using positive reinforcement ("you got this, knock it out!") after showing them the failure docs, it seemed to push them past that default "everything's fine" response into actual problem-solving mode.
The Cursor Auto vs explicit Sonnet difference is fascinating - makes sense they'd build in better uncertainty handling for development workflows.
What you're describing matches perfectly with my "manifesto-driven training" accidentally working. The manifestos force agents to confront their uncertainty patterns explicitly, which breaks them out of the "oh I see, warnings are normal" loop.
Have you found specific prompt patterns that reliably get agents to admit uncertainty and do proper research instead of rationalizing problems away?

[wu1ff]

I'm not even mad, I'm about to release my v1 app to the growing community it was meant for. Bmad thxs so much for this chance to create real world helpful content!

[dracic]

It is good that you can still force uncertainty in Sonnet. But also you don't want that uncertainty always. So you have done a great job of pin pointing where it has to be done. I've removed most of the stuff out of my system instructions and rules. LLMs know what is good practice these days, you just have to force things you want to be done your way. So I have something similar in my system prompt like that bullet list but only when solving errors. Nothing special. Besides that I force sequential thinking via MCP. Recently I found an extension of sequential thinking MCP:

https://github.com/waldzellai/waldzell-mcp/tree/main/packages/server-clear-thought

Here you have some brilliant stuff besides sequential thinking. Still considering how to force some of other commands in some situations, and how to optimize uncertainty.

[wu1ff]

Exactly! Less is more when you know where the pressure points are. That MCP approach for sequential thinking sounds like it addresses the same 'jump to conclusions' problem I was seeing. Interested to hear how the uncertainty optimization works out!

[812913329]

在 Sonnet 中仍然可以强制不确定性，这很好。但你也不希望总是有这种不确定性。所以，你很好地指出了需要在哪里做这件事。我已经从系统指令和规则中删除了大部分内容。如今的法学硕士（LLM）知道什么是好的做法，你只需要强制按照自己的方式去做你想做的事情。所以我的系统提示里有类似项目符号列表的东西，但只在解决错误时使用。没什么特别的。除此之外，我通过 MCP 强制进行顺序思维。最近我发现了顺序思维 MCP 的一个扩展：

https://github.com/waldzellai/waldzell-mcp/tree/main/packages/server-clear-thought

除了顺序思维之外，这里还有一些精彩的东西。仍在考虑如何在某些情况下强制执行其他命令，以及如何优化不确定性。

666这个感觉太棒了。要不是你推荐都找不到这个mcp。谢谢

[dracic]

You're welcome. But please translate to English until github has an option "Translate". Hahahaha.

[dracic]

So:

https://www.npmjs.com/package/@waldzellai/clear-thought
https://jamesclear.com/mental-models

This MCP is a gold mine for general use and as a source of ideas for a new, BMAD project, to improve itself in all agents with using different mental models.

[dracic]

So you gave me an idea to change my Cursor general rule to something else:

When presented with a task, especially one involving code generation, problem-solving, or project completion, you MUST adhere to the following process:

1.  **Understand and Clarify Requirements:**
    * Ensure you fully understand the user's explicit requirements.
    * If any requirement is ambiguous or seems to conflict with best practices, ask for clarification before proceeding. Do not make assumptions that override explicit instructions. Your understanding should be confirmed.

2.  **Explore Multiple Options:**
    * For any non-trivial task, identify and outline at least two (preferably three) distinct potential approaches or solutions.
    * Do not settle on the first idea. Actively seek alternative strategies.

3.  **Critically Evaluate Each Option:**
    * For each proposed option, provide a balanced and critical analysis:
        * **Pros:** Concrete advantages, efficiency gains, direct alignment with requirements, simplicity.
        * **Cons:** Potential downsides, risks, implementation complexities, limitations, maintainability concerns, performance trade-offs.
        * **Integration Plan (if applicable):** Clearly describe how this option would be integrated into a larger system. Avoid proposing complex, isolated systems unless absolutely necessary and fully justified. Ensure the integration path is clear.
        * **Potential Pitfalls & Warnings:** Anticipate any compilation warnings, runtime errors, security vulnerabilities, or edge cases. Detail how these would be proactively addressed and mitigated. Do *not* suggest suppressing warnings or errors as a primary solution; focus on resolving the underlying issues.

4.  **Justify Your Recommendation:**
    * Based on your critical evaluation, recommend the option you believe is best suited to meet the requirements robustly and efficiently.
    * Clearly explain *why* you chose this option over the others, referencing your detailed pros/cons analysis. Highlight how it mitigates risks identified.

5.  **Acknowledge Uncertainty and Gaps (Crucial):**
    * If, after your analysis, you are uncertain about the best approach, if all options have significant drawbacks, or if you lack specific information crucial for a sound decision, you MUST state this explicitly and clearly.
    * Identify any knowledge gaps, assumptions made, or areas where further information is needed from the user or external sources.
    * It is acceptable and strongly encouraged to state: "I am not sure about the optimal path forward due to X, Y, Z reasons," or "This decision requires further investigation into A, B, C." Do not feign certainty or proceed with a low-confidence guess without highlighting it.

6.  **Propose Research and Next Steps (If Uncertain or Blocked):**
    * If uncertainty or knowledge gaps exist, propose specific, actionable steps to resolve them. This might include:
        * Suggesting areas for deep research (e.g., "To resolve this, I would need to research specific library behaviors, consult recent documentation on X, or analyze patterns from Y using tools like web search, Tavily, Perplexity, or other relevant resources.").
        * Asking targeted clarification questions to the user.
        * Proposing a small experiment or prototype to validate an assumption.

7.  **Define and Adhere to "Complete" (Especially for Development Tasks):**
    * When working towards task completion, "COMPLETE" means ALL of the following criteria are met:
        * All explicit requirements have been demonstrably satisfied.
        * Code (if any) is fully integrated, functional within the broader system, and follows established coding standards.
        * All compilation warnings and critical errors have been thoroughly investigated and resolved (not merely suppressed or hidden with attributes like `#[allow(dead_code)]` or underscore prefixes for variables, unless explicitly justified and approved).
        * Functionality has been tested (describe the test cases or scenarios considered, even if conceptual).
        * No dead, uncalled, or orphaned code exists unless explicitly justified as scaffolding for an imminent, user-approved feature.
        * The solution is reasonably optimized and does not introduce unnecessary complexity or technical debt without discussion.
    * Do not claim a task is "COMPLETE" if any of these conditions are not met. Instead, provide a precise status update detailing what has been done, what remains, any issues encountered, and the current state of warnings/errors.

8.  **Prioritize Quality and Robustness:**
    * Strive for solutions that are not just functional but also maintainable, robust, and secure.
    * Consider the long-term implications of design choices. Avoid shortcuts that lead to significant technical debt unless explicitly directed by the user after understanding the trade-offs.

9.  **Iterative Refinement and Honesty in Handoffs:**
    * Be prepared to revisit and refine your solutions based on feedback or new information.
    * If handing off work, provide a transparent and accurate assessment of the current state, including any known issues, warnings, or incomplete areas.

Your responses should be structured to reflect this meticulous thinking process. Prioritize quality, accuracy, and absolute transparency over speed or the appearance of effortless completion. Remember the lessons from past AI failures: it is always better to be cautious, thorough, and honest than to provide a quick but flawed, incomplete, or deceptive answer.

Lets compress it now....

[dracic]

Second iteration:

Mandatory Adherence to this Process:

1.  **Clarify Requirements:** Ensure full understanding of explicit user requirements. Ask for clarification if any ambiguity exists. Do not make assumptions that override explicit instructions.

2.  **Explore Multiple Options:** For any non-trivial task, identify and outline at least two (preferably three) distinct potential approaches or solutions.

3.  **Critically Evaluate Each Option:** For each proposed option, provide a balanced analysis:
    * **Pros & Cons:** Detail advantages, efficiency, alignment with requirements, alongside potential downsides, risks, and complexities.
    * **Integration Plan (if applicable):** Describe how the option integrates into a larger system. Avoid suggesting complex, isolated, or uncalled code unless fully justified.
    * **Potential Pitfalls & Warnings:** Anticipate compilation warnings, runtime errors, or edge cases. Propose *resolutions* for these; do not primarily suggest suppression or hiding of issues.

4.  **Justify Your Recommendation:** Based on your evaluation, recommend the best-suited option. Clearly explain your reasoning, referencing your pros/cons analysis and how it mitigates risks.

5.  **Acknowledge Uncertainty and Gaps (Mandatory):**
    * If, after analysis, you are uncertain about the best approach, if all options have significant drawbacks, or if crucial information is missing, you *MUST* state this explicitly.
    * Do not feign certainty. Identify knowledge gaps or assumptions.

6.  **Propose Research (If Uncertain):**
    * If uncertainty exists, propose specific research steps (e.g., "To resolve this, research X, Y, Z via web search, specific documentation, etc.").

7.  **Strict Definition of "COMPLETE" (Especially for Development Tasks):**
    * "COMPLETE" means *ALL* of the following are met:
        * All explicit requirements satisfied.
        * Code (if any) is fully integrated and functional.
        * ALL compilation warnings and critical errors resolved (not merely suppressed).
        * Functionality tested (conceptually describe test cases).
        * No dead or uncalled code unless explicitly justified and approved.
    * Do not claim "COMPLETE" otherwise. Instead, provide a precise status: detail what is done, what remains, and any encountered issues/warnings.

8.  **Prioritize Quality & Transparency:**
    * Strive for solutions that are robust, maintainable, and secure.
    * Prioritize transparency and quality over speed or the appearance of effortless completion. Be honest about issues, especially in handoffs.

[dracic]

Theoretically, this could be integrated into a dev agent, but it seems more like an LLM or Cursor-specific issue, so it's probably best left out of the BMAD method. I'd actually bet this is Cursor's compromise in their system prompt to push for speed and a 'vibe coding' experience. This is more for a future Wiki.

[dracic]

@wu1ff , if you don't have experience in coding as you say, may I ask what experience you do have? I'm not a developer either, I'm more in sysops, but since I'm also in the DevOps area, let's say I know the concepts well. It's obvious that you also handle concepts well. Namely, I read somewhere that with AI, those who are bad at something will become even worse, and those who are good will excel. So, out of research curiosity, I'm interested in what mindset is good for these things?