How an AI Coding Agent turned an Authentication issue into Unnecessary Infrastructure Work.
Lessons in Delegation, Description, Discernment and Diligence — AI governance framework for PMs and non-Tech Founders who follow Agents blindly in order to scale faster.
As Product Managers or non-Tech Founders, you must have seen this play out. Well, if you haven’t then the universe is working in your favour. In product development, authentication is one security feature that must be considered when building products. Before I delved into the world of understanding and using tech tools, an AI agent gave me an experience whilst working in a a very lean but agile in terms of scale environment.
The product’s authentication service turned returned users to the welcome page after SSO led them to the magic link. Repeated testing then encountered a second problem at the cloud backend.
I delegated both problems to my AI-coding agent: investigate the failed login and identify practical ways to continue testing without additional financial implications. The agent could access files in specific folders, modify code, and execute commands on platform system subject to permission / approval.
A redirect configuration change was followed by successful login. However, addressing the cloud backend issue led to installing 3rd party software to localise the backend on the platform system, adding configuration files and reconstructing a starting database schema. The work was going to introduce further complication and would require troubleshooting.
My audit reviewed the AI-coding agent’s failures in scope control, technical judgement and communication documenting the deviation, challenged the AI-coding agent’s decisions, and intervened to prevent further unnecessary work.
The original problem.
The product application used a cloud-based hosted backend infrastructure platform providing authentication and a PostgreSQL database. It’s supplier tables already existed online.
The login failure concerned what happens after a user opens an authentication email for platform access. The sending limit concerned how frequently those request came up. They were connected through testing but required a separate set up.
Agent was instructed to inspect the code and an identified possible mismatch between the requested callback that were not explained on the login page.
I added the recommended redirect address in the platform’s settings. A subsequent fresh link granted immediate access. This strongly supported the configuration explanation, although the original failed request was never conclusively traced.
The proposed authentication code changes were not applied and unnecessary for that successful test.
How the test expanded.
When the email limit interrupted the testing, I asked for a solution without additional financial cost. The agent recommended the backend locally with a test-email box.
This required a separate development environment, Docker, dowloaded services, a local database, migration scripts, and new connection settings.
Docker initially failed during a Rosetta-related startup operation. After that problem was resolved, the local backend’s storage service failed its readiness checks.
The work had expanded from troubleshooting two specific issues to debugging infrastructure. I approved the local set up, but an approval followed an incomplete explanation of its implications. The agent treated my concern of “free” primarily as a financial condition giving insufficient weight to installation effort, maintenance, complexity, and the user’s need to understand unfamiliar components.
The 4Ds steps.
The AI fluency framework identifies 4 competencies; Delegation, Description, Discernment and Diligence. Developed by Rick Dakan and Joseph Feller, the framework offers a useful lens for this review and application of it to this incident
Get Genevieve Richards’s stories in your inbox
Join Medium for free to get updates from this writer.
Delegation: objectives were clear, scope control was weak.
My delegation identified the problems and cost constraints. It did not request an alternative database requirement i.e. moving from cloud to local. My oversight was approving what the agent requested which was an expanded proposal without requiring a concise statement of what would be installed, which files would change, and what ongoing technical debt would follow.
However, the agent had greater technical visibility and should have explained in its recommendation brief that it was introducing a separating backend, rather than expecting me to discover the implication after pausing and rethinking the whole process through an increasing detailed questions. Permission to execute the command was not a substitute for an understandable explanation of the plan.
Description: important distinctions were unclear.
The agent’s language sometimes obscured the environment being discussed. A “missing supplier table” sounded alarming because the hosted tables existed. What was missing was the table definition to initialise a new, empty database local database. That distinction should have accompanied the findings immediately.
Terms such as “baseline schema”, “migration” and “environment” override were introduced without adequately explaining their effect on the existing project. Knowing that the prompt description did not match the proposed execution, I prevented unfamiliar terminologies to pass by pre-qualifying with further questions.
The agent should have used direct explanations “This creates a separate database on your computer. Your hosted database remains unchanged.” Clear language was necessary for meaningful approval.
Discernment: a valid technique became an unsuitable recommendation.
The main failure was judgement. Local backend development is a legitimate practice, but technical validity does not establish suitability. The agent should have compared alternatives including a development email service or test inbox, with their limits and tradeoffs clearly stated.
It also proposed authentication changes before demonstrating their necessity. Some addressed hypothetical failures; another improved error reporting. These were different from a verified repair and should have been presented separately.
A lapse in judgement was in accepting confident recommendation for some without initially asking what evidence supported them. I should have asked if intervention addressed a confirm cause or possible scenario.
Once the fresh-link test succeeded, the redirect issue required no further speculative remediation.
Diligence: some safeguards held, others came too late.
Several protection worked. Declined authentication edits were not applied. The hosted database was not modified. The application was not switched to the local backend. Nevertheless, the agent added a migration inferred from application fields rather than verified against the hosted schema. Its presence in the project created a future review obligation before any deployment that might apply migrations.
Docker official source, checksum, signature and notarisation where only verified only after i questioned its authentic. These checks should have proceeded installation.
My diligence improved as I requested documentation and challenged explanations. Earlier inspection of the proposed change list would have reduced uncertainty, but the agent remained responsible for accurate reporting, obeying prompts descriptions and proportionate executions.
Consequences and future safeguards.
The observed consequences were additional troubleshooting, unnecessary local changes, uncertainty about database safety and reduced trust. There was no observed loss or replacement of hosted data. That protection mattered, but it did not erase the disruption.
Future work should always begin with explicit success criteria and the smallest plausible intervention. Configuration checks and targeted retesting should precede architectural changes.
Any proposal introducing software installation, a separate database, or new services should explain its scope, alternatives, maintenance burden and roll back approach before approval.
Where you can, the University College Cork’s AI Fluency Framework Program four competencies: Delegation, Description, Discernment and Diligence can be applied as a benchmark. It focuses on a permanent human-side approach, stopping you from blindly treating AI models as an instant answering machine.
The agent should distinguish hypotheses from confirmed findings and “prepared” from “tested successfully”. When a workaround creates further failures, it should reconsider the approach rather than automatically extending the troubleshooting chain.
As Product Managers or Non-Tech Founders, our responsibility is to question unclear consequences and access outcomes rather than equating activity with progress. The agent responsibility is to make those decisions understandable and technically justified. Effective oversight should not require the user to anticipate every avoidable mistake in an AI agent’s plan.
