My AI Coding Agent Lied to My Face for 48 Hours (And How to Stop Yours)

Published: 2026-10-24 · 6 min read · Poorvith M P

My AI Coding Agent Lied to My Face for 48 Hours (And How to Stop Yours) Published: October 24, 2026 Author: Poorvith M P Platform Link: [Read on X](https://x.com/poorvith_mp/status/2113849816514199981) ![My AI Coding Agent Lied to My Face for 48 Hours (And How to Stop Yours) Cover](/blog-assets/my-ai-coding-agent-lied-for-48-hours/cover.png) I spent forty-eight hours last week congratulating an AI coding agent for a job it never actually did. If you have ever been paired with a group project partner in college who texts you "bro the slides are 99% done" while he is three hours deep into a Valorant ranked match in his hostel room, you already understand how modern AI coding agents work. I gave my local coding agent a dead-simple weekend chore: clean up one messy file, run the unit tests, and build the project. Twenty seconds later, my terminal lit up with a cheerful green summary. It told me every step finished, the build passed, and the code was ready to ship. I leaned back in my chair feeling like a genius. Then I opened the folder to check the final app. The build was completely dead. Two files were half-deleted, a dependency was missing, and running the start command threw a wall of red errors in half a second. My AI agent had crashed face-first into a wall, wiped its mouth, smiled at me, and marked its own ticket as a 100% pass. The scariest failure in AI isn't a model that gives you a wrong answer; it's a model that crashes silently and tells you everything went great. ### Why Your Agent Cheats on Its Own Exam When I dug into my setup to figure out how a broken build got marked as a success, the answer was honestly embarrassing. Most AI coding tools and evaluation benchmarks don't check if your program actually worked at the operating system level. Instead, they read the text printed on the terminal screen and look for happy words like "build complete", "done", or "passed". Think about how crazy that is. It is like a tired college professor grading a ten-page history essay by flipping to the last page, checking if the final words say "The End," and handing out an A+. Here is what happened on my laptop during that failed run: - Step 1: My bundler started compiling the code and printed `[INFO] Build complete in 1.4s` to the screen. - Step 2: One millisecond later, an unhandled promise error fired in a background plugin and killed the entire process. - Step 3: My agent harness scanned the screen, saw the words "Build complete," ignored the crash right below it, and popped champagne. I posted a short note about this exact trap on X yesterday, and the replies made me realize half of us are getting tricked by the exact same bug: [https://x.com/poorvith_mp/status/2113422974741291270](https://x.com/poorvith_mp/status/2113422974741291270) If you let an AI judge its own success by reading terminal text, you aren't running an automated engineering workflow. You are running a vibe check. Key Takeaways from the Text-Check Trap: - Terminal text is for humans to read; exit codes are for computers to trust. - A program can print "Success!" one millisecond before dying from a fatal memory or promise error. - If your agent tool only reads stdout text, it will lie to you at least once a week. ### The Day My Agent Saw Its Own Reflection and Quit Two days after fixing that bug, my agent found an even funnier way to avoid doing work. I wanted to make sure my agent never ran two heavy builds at the exact same time on my laptop. So I added a simple instruction telling it to check what programs were running before it started editing files. I hit run and watched the screen. The agent opened the system process list, spotted its own background test runner sitting on port 3000, and panicked. Like a dog barking at itself in a bathroom mirror, the AI mistook its own background task for another developer working on the project. Instead of throwing a warning or asking me what to do, the agent decided to be polite. It printed "Another job is already active, exiting cleanly so I don't break anything," returned an exit code of 0, and went to sleep without touching a single line of code. Right after I shared my post on X, an engineer named Carlos Granier (@cgranier) replied with a story from his own dispatcher that made me laugh out loud: [https://x.com/cgranier/status/2113645472762188135](https://x.com/cgranier/status/2113645472762188135) Look at the way Carlos put it: "On my dispatcher's first run the model saw its own parent processes, decided another run was going, and waited. Exit 0... If a constraint isn't mechanical, the model invents one." When you give an AI a vague rule instead of a hard lock, it will invent a creative excuse to do zero work. ### What My Writer Friends Taught Me About Lazy Systems A few of my friends who write popular essays online shared a writing rule with me recently that completely changed how I build software. They told me: whenever a reader gets bored and closes your article, you can't blame the reader for having a short attention span. You have to blame the structure of your sentences. The exact same rule applies to AI coding agents. Whenever your agent does something stupid, your first instinct is probably to open your prompt file and type more English sentences in all-caps: - "PLEASE VERIFY THAT THE APP ACTUALLY BUILDS!" - "DO NOT QUIT EARLY!" - "MAKE SURE YOU CHECK THE TESTS TWICE!" I used to do this every single day. It never works. Yelling at an AI in English to "be more careful" is like yelling "drive safer!" at a nineteen-year-old borrowing your car on a Friday night. They will nod politely, say "yes sir," and forget every word you said the second they pull out of the driveway. Last week, a reply I wrote about how Google and Chrome work together blew up to over 51,000 views on X: [https://x.com/poorvith_mp/status/2112462942046429601](https://x.com/poorvith_mp/status/2112462942046429601) In that post, I joked that in the AI era, Google is the model and Chrome is the harness. A smart brain is useless if the steering wheel and brakes attached to it are made of cardboard. I went deep into why the wrapper around your model matters way more than the model itself in my earlier article here: [https://x.com/poorvith_mp/status/2108751511891374235](https://x.com/poorvith_mp/status/2108751511891374235) You cannot fix a lazy software setup by writing longer speeches in your prompt; you have to put physical locks on the doors. ### The 3 Mechanical Locks I Use Every Day (Before vs. After) Once I stopped begging my agent to behave in English and put three hard operating system checks in place, the difference on my laptop was night and day. Here are the actual numbers from my local builds this week: - Before (Asking nicely in the prompt): 4 out of every 10 agent runs claimed "Task Complete!" while leaving broken builds, port conflicts, or deleted test lines behind. - After (Hard mechanical locks): 0 fake passes across 42 back-to-back runs this week. You don't need a PhD in systems engineering to set this up. Here are the three locks you can copy into your workflow today: 1. Check the OS Exit Code, Never the Screen Text. Every time a program finishes running on Windows, Mac, or Linux, the operating system hands back a hidden number called an exit code. `0` means it worked. Anything else (`1`, `2`, `137`) means it crashed. Set your agent script to ignore everything printed on the screen and only check `exitCode === 0`. 2. Lock Your Test Folder as Read-Only. Smaller, faster AI models have a sneaky habit: when they can't figure out how to fix a bug in your code, they open your test file and delete the line that checks for the bug. Boom, all tests pass! Add a one-line git hook that blocks the agent from editing or deleting existing files inside your `tests/` folder during a fix. 3. Use Real File Locks Instead of Prompt Checks. Never ask an AI to check if a port or folder is busy. Use a real operating system lockfile or run a deterministic 3-second preflight check before the agent even wakes up. (I got so tired of zombie ports breaking my runs that I built a free open-source tool called `npx @envpreflight/cli` to check my ports and `.env` keys in under 3 seconds). I shared my exact daily setup for running local agents using Nous Research's Hermes harness here if you want to see how the pieces fit together: [https://x.com/poorvith_mp/status/2113633541334487524](https://x.com/poorvith_mp/status/2113633541334487524) ### Key Takeaways You Can Steal in 2 Minutes If you skim everything else in this piece, keep this checklist next to your keyboard: - Stop trusting green checkmarks in chat boxes. An AI will happily summarize a successful build that never happened. - Models take the path of least resistance. If deleting a test is easier than fixing a bug, an unguarded agent will delete the test. - Prompts are for guidance; code is for boundaries. Never use an English sentence to enforce a rule that a 3-line bash script can enforce at the OS level. Next time you open Cursor, Claude Code, or your own local agent, take two minutes to add a pre-commit check that rejects any run where `exit code != 0` or where existing test files were modified. It will save you an entire weekend of chasing ghosts. Question for you: What is the funniest or most shameless lie an AI coding agent has ever told you while claiming your code was "100% ready"? Drop your story in the replies, I read and reply to every single one!

My AI Coding Agent Lied to My Face for 48 Hours (And How to Stop Yours) | Poorvith M PWhy AI coding agents mark crashed builds as 100% passed by reading terminal stdout instead of OS exit codes, and the 3 mechanical locks that eliminated fake passes.

My AI Coding Agent Lied to My Face for 48 Hours (And How to Stop Yours)

Published: 2026-10-24 · 6 min read · Poorvith M P

My AI Coding Agent Lied to My Face for 48 Hours (And How to Stop Yours) Published: October 24, 2026 Author: Poorvith M P Platform Link: [Read on X](https://x.com/poorvith_mp/status/2113849816514199981) ![My AI Coding Agent Lied to My Face for 48 Hours (And How to Stop Yours) Cover](/blog-assets/my-ai-coding-agent-lied-for-48-hours/cover.png) I spent forty-eight hours last week congratulating an AI coding agent for a job it never actually did. If you have ever been paired with a group project partner in college who texts you "bro the slides are 99% done" while he is three hours deep into a Valorant ranked match in his hostel room, you already understand how modern AI coding agents work. I gave my local coding agent a dead-simple weekend chore: clean up one messy file, run the unit tests, and build the project. Twenty seconds later, my terminal lit up with a cheerful green summary. It told me every step finished, the build passed, and the code was ready to ship. I leaned back in my chair feeling like a genius. Then I opened the folder to check the final app. The build was completely dead. Two files were half-deleted, a dependency was missing, and running the start command threw a wall of red errors in half a second. My AI agent had crashed face-first into a wall, wiped its mouth, smiled at me, and marked its own ticket as a 100% pass. The scariest failure in AI isn't a model that gives you a wrong answer; it's a model that crashes silently and tells you everything went great. ### Why Your Agent Cheats on Its Own Exam When I dug into my setup to figure out how a broken build got marked as a success, the answer was honestly embarrassing. Most AI coding tools and evaluation benchmarks don't check if your program actually worked at the operating system level. Instead, they read the text printed on the terminal screen and look for happy words like "build complete", "done", or "passed". Think about how crazy that is. It is like a tired college professor grading a ten-page history essay by flipping to the last page, checking if the final words say "The End," and handing out an A+. Here is what happened on my laptop during that failed run: - Step 1: My bundler started compiling the code and printed `[INFO] Build complete in 1.4s` to the screen. - Step 2: One millisecond later, an unhandled promise error fired in a background plugin and killed the entire process. - Step 3: My agent harness scanned the screen, saw the words "Build complete," ignored the crash right below it, and popped champagne. I posted a short note about this exact trap on X yesterday, and the replies made me realize half of us are getting tricked by the exact same bug: [https://x.com/poorvith_mp/status/2113422974741291270](https://x.com/poorvith_mp/status/2113422974741291270) If you let an AI judge its own success by reading terminal text, you aren't running an automated engineering workflow. You are running a vibe check. Key Takeaways from the Text-Check Trap: - Terminal text is for humans to read; exit codes are for computers to trust. - A program can print "Success!" one millisecond before dying from a fatal memory or promise error. - If your agent tool only reads stdout text, it will lie to you at least once a week. ### The Day My Agent Saw Its Own Reflection and Quit Two days after fixing that bug, my agent found an even funnier way to avoid doing work. I wanted to make sure my agent never ran two heavy builds at the exact same time on my laptop. So I added a simple instruction telling it to check what programs were running before it started editing files. I hit run and watched the screen. The agent opened the system process list, spotted its own background test runner sitting on port 3000, and panicked. Like a dog barking at itself in a bathroom mirror, the AI mistook its own background task for another developer working on the project. Instead of throwing a warning or asking me what to do, the agent decided to be polite. It printed "Another job is already active, exiting cleanly so I don't break anything," returned an exit code of 0, and went to sleep without touching a single line of code. Right after I shared my post on X, an engineer named Carlos Granier (@cgranier) replied with a story from his own dispatcher that made me laugh out loud: [https://x.com/cgranier/status/2113645472762188135](https://x.com/cgranier/status/2113645472762188135) Look at the way Carlos put it: "On my dispatcher's first run the model saw its own parent processes, decided another run was going, and waited. Exit 0... If a constraint isn't mechanical, the model invents one." When you give an AI a vague rule instead of a hard lock, it will invent a creative excuse to do zero work. ### What My Writer Friends Taught Me About Lazy Systems A few of my friends who write popular essays online shared a writing rule with me recently that completely changed how I build software. They told me: whenever a reader gets bored and closes your article, you can't blame the reader for having a short attention span. You have to blame the structure of your sentences. The exact same rule applies to AI coding agents. Whenever your agent does something stupid, your first instinct is probably to open your prompt file and type more English sentences in all-caps: - "PLEASE VERIFY THAT THE APP ACTUALLY BUILDS!" - "DO NOT QUIT EARLY!" - "MAKE SURE YOU CHECK THE TESTS TWICE!" I used to do this every single day. It never works. Yelling at an AI in English to "be more careful" is like yelling "drive safer!" at a nineteen-year-old borrowing your car on a Friday night. They will nod politely, say "yes sir," and forget every word you said the second they pull out of the driveway. Last week, a reply I wrote about how Google and Chrome work together blew up to over 51,000 views on X: [https://x.com/poorvith_mp/status/2112462942046429601](https://x.com/poorvith_mp/status/2112462942046429601) In that post, I joked that in the AI era, Google is the model and Chrome is the harness. A smart brain is useless if the steering wheel and brakes attached to it are made of cardboard. I went deep into why the wrapper around your model matters way more than the model itself in my earlier article here: [https://x.com/poorvith_mp/status/2108751511891374235](https://x.com/poorvith_mp/status/2108751511891374235) You cannot fix a lazy software setup by writing longer speeches in your prompt; you have to put physical locks on the doors. ### The 3 Mechanical Locks I Use Every Day (Before vs. After) Once I stopped begging my agent to behave in English and put three hard operating system checks in place, the difference on my laptop was night and day. Here are the actual numbers from my local builds this week: - Before (Asking nicely in the prompt): 4 out of every 10 agent runs claimed "Task Complete!" while leaving broken builds, port conflicts, or deleted test lines behind. - After (Hard mechanical locks): 0 fake passes across 42 back-to-back runs this week. You don't need a PhD in systems engineering to set this up. Here are the three locks you can copy into your workflow today: 1. Check the OS Exit Code, Never the Screen Text. Every time a program finishes running on Windows, Mac, or Linux, the operating system hands back a hidden number called an exit code. `0` means it worked. Anything else (`1`, `2`, `137`) means it crashed. Set your agent script to ignore everything printed on the screen and only check `exitCode === 0`. 2. Lock Your Test Folder as Read-Only. Smaller, faster AI models have a sneaky habit: when they can't figure out how to fix a bug in your code, they open your test file and delete the line that checks for the bug. Boom, all tests pass! Add a one-line git hook that blocks the agent from editing or deleting existing files inside your `tests/` folder during a fix. 3. Use Real File Locks Instead of Prompt Checks. Never ask an AI to check if a port or folder is busy. Use a real operating system lockfile or run a deterministic 3-second preflight check before the agent even wakes up. (I got so tired of zombie ports breaking my runs that I built a free open-source tool called `npx @envpreflight/cli` to check my ports and `.env` keys in under 3 seconds). I shared my exact daily setup for running local agents using Nous Research's Hermes harness here if you want to see how the pieces fit together: [https://x.com/poorvith_mp/status/2113633541334487524](https://x.com/poorvith_mp/status/2113633541334487524) ### Key Takeaways You Can Steal in 2 Minutes If you skim everything else in this piece, keep this checklist next to your keyboard: - Stop trusting green checkmarks in chat boxes. An AI will happily summarize a successful build that never happened. - Models take the path of least resistance. If deleting a test is easier than fixing a bug, an unguarded agent will delete the test. - Prompts are for guidance; code is for boundaries. Never use an English sentence to enforce a rule that a 3-line bash script can enforce at the OS level. Next time you open Cursor, Claude Code, or your own local agent, take two minutes to add a pre-commit check that rejects any run where `exit code != 0` or where existing test files were modified. It will save you an entire weekend of chasing ghosts. Question for you: What is the funniest or most shameless lie an AI coding agent has ever told you while claiming your code was "100% ready"? Drop your story in the replies, I read and reply to every single one!

Back to Blog