Early conversations focused more on the overall vision than on concrete details. The client also mentioned how the communication with the developer worked:
“The previous developer is deaf and non-verbal. We communicated only by messages.” – the client explained.
We noted it and continued with the review. Knowing that all communication had taken place through messages helped us understand the setup and decide where to start the audit.
No History, No Structure – The First Signs That Something Felt Slightly Off
We first needed to see how the software was built. Normally, software projects are stored in a system that tracks changes. In this case, the project didn’t work like that. The client shared access to two folders on a server. One was called “test”, and the other “production.” Folders contained the application files. But there was no history, no clear structure, and no explanation of how the project evolved.
Among the files, a few stood out. They looked like conversations:
“Everything disappeared!!!”
“I have to write this again from scratch.”
“Let’s continue tomorrow at 10.”
“I can’t send you images; something is broken.”
At first glance, it looked like notes from discussions with a developer. But as we read more carefully, we started to have doubts. The same conversation appeared several times. Each time, it was copied from the beginning, as if the developer wanted to keep the full context.
The “Developer” Behind the Code
After looking closely at how these conversations were structured, it strongly suggested they were generated by an AI assistant built into a coding tool. That’s why the messages felt human, and the replies were instant.
Suddenly, the client’s earlier comment about a “deaf and non-verbal developer” took on a different meaning. The “developer” never spoke, never listened, and there was no clear evidence that a real person was responsible for the work.
We asked the client how this collaboration started. We returned to this question more than once, but never received a clear answer. Information about contact and the “developer’s” background remained unclear, and we didn’t fully understand how the cooperation began. At the time, this didn’t raise concern. Looking back, we know that situations like this can happen to anyone.
The Damage Was Already Done
This situation had real consequences for the project. Because the AI-generated changes were saved directly to files:
- No one checked if the changes made sense
- Nothing tracked what was modified or removed
- Working parts of the application could be overwritten
- Mistakes could not be undone
A client reached out for a consultation after a feature broke their application. But the codebase was hard to understand, even for an experienced team.
We’re Sharing This Story to Help Clients Stay Safe
AI is entering the market fast. Along with real benefits, it also creates new ways to mislead clients. For someone without technical experience, AI-generated communication can sound like a real developer. Clear answers, confident explanations, and quick responses can easily build trust.
For a technical team, the signals are different. Issues in the code, lack of structure, and missing ownership become much easier to spot.
This story is real, and it’s not unique. AI can support development, but it cannot replace human ownership, transparency, and accountability. We’re sharing this story to help clients spot warning signs early and avoid situations where no one takes responsibility for the code.
Have doubts about your code? Let’s talk.
This article is based on a real situation. Details have been anonymized and generalized to protect all parties involved.
