A lesson in overcorrection, from an AI-assisted builder who is scared stiff of shipping spaghetti and slop.
I am building Porch Light, an agent th...
For further actions, you may consider blocking this person and/or reporting abuse
The byte-identity test has the same shape as the 28 that passed. It proves the vendored
log.pymatches the original, not that the deployed runtime imported it instead of the framework's built-in logger, which is the gap that made the redaction processor a control that never ran. The thing that did prove it was the accident:[redacted:document_content]showed up in CloudWatch, and that marker cannot exist unless your processor executed inside the runtime. Asserting that marker in the deployed log stream after each deploy is the check CI cannot be, as long as the smoke event carries a key worth redacting.You're right, and it stings a little. The byte-identity test answers a different question. It proves the two copies match, not that the runtime imported mine instead of the framework's.
The marker is the only thing that proved it ran. Adding that assertion to the post-deploy check.
Funny part: I already do this for a different control. My containment test invokes the deployed agent with a tool that is not on the allowlist and asserts the block shows up in the log stream. Same pattern. I applied it to the allowlist and not the logger.
This hits so close to home. The hardest thing to discipline when directing coding agents is their instinct to build enterprise-grade scaffolding around a throwaway spike.
When an LLM sees a prompt to "verify Bedrock invocation", it immediately wants to generate structured config layers, custom exception hierarchies, and retry policies before it even checks if the raw payload returns cleanly.
We started enforcing a strict rule for exploratory spikes: zero abstraction allowed in Phase 0. Single flat script, direct credentials check, single invocation, assert output, print receipt, exit. Once raw execution is proven against reality, only then do we let the agent touch architecture.
Thank you for sharing. Yes, this is something I'm starting to realize. Kiro and Claude go full bore unless I restrain them, and my mistake was taking their word on what best practice meant for a throwaway. Your zero abstraction approach is very helpful and would have saved me the sprawl.
The distinction between “the work is correct” and “this is the right work to be doing” is important.
An agent can rigorously implement and review the task it has been given while completely missing that the task deserves a different level of investment—or should not exist at all. That makes intent, constraints, and the definition of “enough” part of the engineering work, not just preparation for it.
I also like your idea of a rigor budget. The human shouldn’t have to second-guess every line, but someone does need to decide what level of evidence the decision warrants and whether the agents are still solving the original problem.
Thank you for reading! Yes, I'm still mulling over how to build towards or implement a rigor budget. I'm not sure if I can set gates or hard rules or... I use Kiro a lot for my IDE so maybe add a steering doc to help.
A steering doc could help, especially if it defines different levels of rigor based on whether the work is exploratory, temporary, or production-bound. The human still decides which level applies.
I'm going to try it on my next build. Interested to see how it goes!
This is a fantastic write-up. You’ve hit on the exact two failure modes the architecture community is currently circling.
Your logging module tests passing 28/28 while the code was never deployed is a textbook Empty Set Trap. The mechanical checks were green, but the population of executed code in production was zero. "A control that has never run in the environment it protects is not a control" — that is the exact boundary between testing syntax and testing semantics.
The duplicate URL bug is the other side of the same coin: a cryptographically perfect suite over wrong output. A duplicate URL is mechanically valid, but semantically wrong. No property test can catch it because they ask "is this a valid URL?" not "is this the correct representation of reality?"
Your conclusion that the human's role is to "decide" is spot on. Agents generate; humans define the semantic boundary. Great post.
Thank you! I appreciate it.
Empty Set Trap is a good name for it and I am stealing it. lol
One thing I am chewing on: would a "no duplicate document URLs per meeting" property have caught this? I think it might have, which makes me wonder whether the limit was the property tests or my own imagination about what could go wrong. Curious what you think.
And yes on the control. I went into this build determined not to fall into that exact trap, and fell in anyway.
You found the exact boundary, and your phrasing is better than mine: the limit was neither the property tests nor your imagination — it was the gap between them. Property testing as a technique covers any property you can state; the suite covered the properties you stated. "No duplicate document URLs per meeting" was stateable, so it was reachable — and the fact that you reached it two days later, from one comment, is the honest measure of how cheap it was. That is not a failure of the method; it is the method working: the hand-check found the miss, the miss became a property, the property now runs forever. The bug cost you twenty minutes and bought a permanent assertion — that trade is a win, and it is worth writing down exactly that way, because most people only publish the case where the method wins.
On Empty Set Trap: steal freely — it is yours now. Terms earn their keep by being useful in other people's mouths, and you just gave it its first independent deployment, plus the better closing line: "I went into this build determined not to fall into that exact trap, and fell in anyway." That sentence is the whole phenomenon — knowing about a trap is not immunity to it. It is the same reason checklists have items for things everyone knows