A developer I know recently found himself locked out of his AI account.
The immediate problem was two-factor authentication.
Something in the authentication process wasn't working, and he couldn't get back into the account.
That alone is frustrating.
But what caught my attention wasn't really the login problem.
It was what was on the other side of the login.
Work.
It wasn't just access to another chatbot
If an AI account were nothing more than a place to ask disposable questions, being locked out would be irritating but fairly easy to work around.
Open another account.
Use another service.
Keep going.
But that isn't how many of us use AI anymore.
The account may contain Projects.
Long-running conversations.
Design discussions.
Experiments.
Research.
Explanations.
Development decisions.
The developer I know had work in the account that mattered to him.
That changes the nature of the problem.
He wasn't merely locked out of a tool.
He was locked away from work he had already done.
When did the account become part of the project?
I suspect this happens to a lot of us without our noticing it.
You start with a conversation.
Then another.
You create a Project.
You work through a problem.
You refine an idea.
You solve something difficult.
You come back to that conversation later because it contains the explanation.
Eventually the AI account contains pieces of your development history.
No single moment announces:
This account is now storing valuable work product.
It just happens.
That's what makes the dependency easy to miss.
Nobody deliberately decides that the only useful record of important work should live inside an AI account.
You simply keep using the tool because it is useful.
Over time, the account becomes more valuable.
The problem is easy to ignore while everything works
Most infrastructure feels permanent right up until the moment it doesn't.
You log in every day.
The authentication works.
The conversations are there.
The Projects are there.
There is no reason to think much about it.
That is exactly why dependencies like this can grow unnoticed.
The AI account starts as a convenience.
Then it becomes part of the workflow.
Then it starts holding project history.
Eventually, losing access to it becomes more than an inconvenience.
You just may not realize that until the door doesn't open.
We already understand this with source code
If somebody told me that the only copy of an important source repository existed on a machine controlled by somebody else, with no backup, I would consider that an obvious risk.
If someone said the only copy of a production database existed on one server, we'd have the same reaction.
We have decades of experience teaching ourselves that important digital assets need another copy.
AI conversations slipped through that mental model because we didn't initially think of them as assets.
They were conversations.
Increasingly, that isn't true.
Some of them are project records.
The most valuable thing may not be the code
One reason this is easy to miss is that the obvious deliverables are often stored somewhere else already.
The source code may be in GitHub.
The compiled product may be on a development machine.
The documentation may exist as files.
So it can appear that the AI conversation itself isn't important.
But sometimes the valuable part is the explanation.
Why did we choose this architecture?
Why did we reject the other approach?
What strange behavior did we discover in the old code?
Which attempted fixes failed?
What constraint must the next worker preserve?
What was the reasoning behind a decision that now looks arbitrary?
That knowledge can be expensive to reconstruct.
The code tells you what exists.
The conversation may tell you why.
I started thinking about my own work
Watching this happen naturally made me look at the way I use AI.
I have long-running development conversations.
Some contain a tremendous amount of project history.
Some record why we made architectural decisions.
Some contain experiments that prevented us from going down the wrong path.
Some document problems that would be expensive to rediscover.
Some are effectively handoffs between stages of a project.
If I suddenly couldn't access those conversations, how much of that knowledge would I have to reconstruct?
That's a much more interesting question than whether I could open another account somewhere.
Of course I could use another AI.
The harder question is whether I could give that AI everything it needed to continue the work.
This isn't really about the provider
The particular incident that prompted this involved one AI service.
I don't think the useful lesson is about that company.
Put enough valuable information into any cloud service and the same basic risk exists.
Accounts get locked.
Authentication systems fail.
Email addresses change.
Phone numbers change.
Services have outages.
Policies change.
Products disappear.
Most of the time none of that happens.
You don't make backups because you expect the disk to fail tomorrow.
You make them because eventually something does.
The useful lesson doesn't depend on how the account problem ends
The developer may regain access.
I hope he does.
But from my perspective, the most useful lesson from the situation doesn't depend on the final outcome.
The vulnerability was already demonstrated.
Valuable work was inside an account.
The legitimate owner couldn't reach it.
That is enough to learn from.
I don't need to know every detail of the support process.
I don't need to know exactly why the authentication failed.
I don't need the story to end badly.
The important part already happened.
The work became inaccessible because the account became inaccessible.
If the conversation matters, keep your own copy
That is the rule I have taken away from the experience.
Not every conversation matters.
Most probably don't.
But when one becomes part of the project, treat it like part of the project.
Extract the decisions.
Save the specification.
Put the accepted architecture somewhere durable.
Keep a copy of the conversation when the conversation itself has continuing value.
Make sure another AI could pick up the project without requiring access to the account where the work originally happened.
Because there is a big difference between losing access to an AI service and losing access to your work.
The first is an inconvenience.
The second can hurt.
If somebody else's account system is the only path to something important, that is worth fixing before the door stops opening.
Related guide
This experience raises a broader question for anyone using AI as part of serious development work: how much of your project's knowledge exists only inside an account controlled by somebody else?