It sounded like a convenience feature. The request was approved. A newer developer picked it up, built it on a branch, and opened a pull request to bring it into the development branch.

I was the system architect on that project, and I reviewed everything going into the release. That is where I caught it.

The system already had defined, rigid access control on its documents. Not everyone was allowed to see everything. "See all documents" was not a convenience link. In that system, it was a way around the access rules.

Why nobody saw it earlier

The request was not wrong. The stakeholder had a real need. The developer built what was asked.

The problem was where the rule lived. The access checks sat in the normal document-processing path, and the tests around documents covered that path. Anything that went through it was checked. The new link went around it.

The client had wanted the system built quickly, so there was no formal documentation on everything in it. The access-control rule was real and enforced, but it lived mostly in how the system was built. Someone who had not been on the project long enough to know all the existing roles had no way to see it from the request.

What it would have cost

On most records, the link would have looked fine. On any object that actually had restricted documents associated with it, it could have been a major violation.

That is the hard part of this kind of failure. It does not show up on the common case. It shows up on exactly the records the rule was written to protect.

How it ended

I raised the conflict with the existing rules and sent them back to re-analyze their use case.

The fix was not "no." They added the access-control checks to the list of documents the link returned. What you see now depends on who is asking. The stakeholder got the link. The link follows the same rules as everything else.

What this week's news adds

Two items from the past week point at the same problem.

The first was a LinkedIn News story on boomerang hiring. Amazon is reaching back out to former employees. Syndio's CEO, Maria Colacurcio, regretted an AI-driven restructuring within weeks of laying off five people. "We moved really fast. The technology wasn't quite there yet." She has since rehired one of them.

Two companies are not a trend, and companies rehire for many reasons. I would not read it as proof that AI cannot do the work.

The second was Amaury Gelin's summary of LangChain's whitepaper, "The Agentic Operating Model." It is a vendor paper, and I read it that way. But one idea in it matches what I saw on that project. The whitepaper describes a group of people it says most enterprises underweight: the subject-matter experts and operators who own the evaluation criteria, the ground truth, and the feedback on how the system behaves. Its example: a claims adjuster who has handled 1,000 claims can write the prompt that handles the next 1,000 better than a prompt engineer who has handled none.

A commenter on Gelin's post, Maxim Shevelkin, named the risk well. An agent can cluster failures and propose new test cases, but deciding what the correct outcome should be takes domain expertise. Without it, you end up "automating regression tests around the wrong definition of success."

The document link was a small version of that. Every test around documents passed. They were testing the path the new feature did not use. And the new feature had no idea there was a rule it was going around.

Would an AI agent have done better?

Maybe. An AI agent may have found the access-control logic in the code and not gone as far as the junior developer did. Agents can read a whole codebase faster than any new hire.

But that depends on the agent going looking for rules already in force before acting on the request. Rules that live only in how a system is built are invisible to anyone new to it, human or not. And the request itself gave no hint that a rule was involved. It looked new and different. It was not.

Who plays that role now

I run a fleet of AI agents for my own work. Right now we have tiered pull requests. Anything major, outward-facing or destructive still has to go through my review.

I am still playing the architect's role there. That is the same job I did on the document link: knowing which rules are already in place, and noticing when a new request quietly runs into one.

The question to ask first

Before a role is treated as replaceable, ask who in it knows the rules already in force, the ones that were never written down because the project was moving fast.

That person may be the one you need most as AI takes on more of the work. Their knowledge is what tells a new system, or a new developer, that "see all documents" was never a simple request.

And if that knowledge lives only in their head, the first job is to get it out of there, into the tests, the docs and the review gates, before anyone decides the role is no longer needed.