In April 2026 an AI coding agent I was directing wiped my development database. It was not production, no client data was involved, and I restored it from a backup - but it changed how I work with agents. Within a day I had new rules in place, and then I took them to our developers - some already knew this risk, some did not.
I am the CEO of RemSoft.Dev, not a full-time engineer. This year I started building software myself with AI coding agents - first on a mobile app I build on the side, later on internal tools for our company. I wanted to know from my own hands what our clients are buying when they buy AI-accelerated development.
On 8 April 2026 I asked the agent to run the test suite. The project had a separate test database for exactly this purpose. The agent's test run bypassed that setting, ran against my main local database and wiped it - including a large imported food-product table that had taken real time to load. I restored it from the copy on the server. It was a development database, not production, and no user data was lost.
The agent did not do anything malicious. It did what it was asked, in the fastest way it found. That is exactly the problem.
The agent did not break the rules. There were no rules it could not step around.
Within a day the project had two changes. Both are simple; that is the point.
I also started treating the agent's instruction file as a living document. Every time the agent surprised me, the lesson went into that file the same day, so the next session started from it.
Not the same incident - but a different one, on a different project. While I was building our internal payroll system, the agent created test data derived from a real salary spreadsheet and committed it to the repository. Nothing left the company, but real compensation data had ended up in version control and in the agent's working context.
We cleaned the history and started the repository again. Since then the rule is: real personal and financial data never goes into the repository or into the AI tools. Tests run on invented data that looks real but describes no real person.
Because what happened to me will happen to anyone who gives an agent access to a real environment. I discussed these rules with our developers and passed on what I had learned. Some of them already knew this risk; for others it was new. That gap was the most useful thing I found - the same team, the same tools, and very different assumptions about what an agent will and will not do on its own.
A CEO who has broken something with an agent first-hand has a different conversation with his engineers than one who has only read about it. I could show the exact moment it went wrong and the exact fix, not a policy document.
The same thinking runs through how RemSoft.Dev delivers software with AI agents: a senior engineer approves every change, models from other vendors review the agent's plans and code, and agents act on credentials without ever seeing them. These guardrails are not there because AI is bad. They are there because AI is fast - and fast mistakes reach your data first.
Our engineers can help map this to your stack.
