What to do if AI takes your job, and what next

What to do if AI takes your job is a practical question wearing an existential coat. The coat is real. A tool did, in an afternoon, work that used to prove you were needed. The practical question is still there underneath: how you pay for the next several months, which of your skills still have a buyer, and which story about yourself you refuse to settle in the first week.

AI took my job now what is the same question on the day after the meeting. The useful answer is sequential. Money first. Then an honest list of tasks. Then one test. A new identity is what people reach for because it feels like motion. It is usually a way to skip the list.

What to do if AI takes your job, in the first month

The first month is not a vocation retreat. It is an operations problem.

Write the runway. Unemployment rules where you live, the date health coverage changes, the bills that are fixed, and the number of months you can last without inventing a number. If you share money with another person, do this on paper with them. A vague sense that you will "figure it out" is how people make a panicked purchase in week two.

Tell the truth to three people who have watched you work. Not the feed. A former manager, a client, a peer who would hire you again for a specific task. Ask which task. Believe the overlap between their answer and the work you can still stand.

Keep a small application rhythm if you need a job soon: a set number of serious conversations a week, not twelve hours of scrolling roles that were written last year. Scrolling feels like effort. It mostly produces the feeling that every door now says the same thing.

Do not post a reinvention. "I am becoming a founder" or "I am done with this field" is a sentence you can earn later, after a test. In the first month it is branding for a panic.

Andre was a support engineer. The company replaced the first-reply layer with a product that drafts answers. He is thirty-four, good at the work, and furious in a way he is trying to call curiosity. The fury is appropriate. The draft is often fine. The second ticket, the angry customer, and the case that will become a legal problem were the part he was actually for. His first month is not a coding bootcamp. It is health insurance, three conversations with people who have seen him untangle a bad case, and a written sample of how he decides when the draft is unsafe to send.

AI took my job: now what the week needs

AI took my job now what, once the bills have a plan, becomes a sorting problem.

Split the old job into two columns.

The tool can draft it. Routine writing, first-pass code, summaries, standard replies, the part of the work that was pattern completion. If this column was most of your week, the role was exposed. That is a fact about the task, not a verdict on your character.

A person still has to own it. Ambiguous requests, a customer who is actually angry, a system that fails in a specific place, a decision someone will be blamed for, work that touches a body, a building, a machine, or a law. Context that was never written down lives here. So does taste, and so does the willingness to say no.

The second column is your inventory. It is not a personal brand. It is a list of tasks a buyer can recognize. If the column is thin, that is also information. You were paid for speed at a pattern, and speed at that pattern got cheap. The next skill has to be chosen, not mourned into existence.

A career change after a layoff has its own order of operations in how to pick a career when the path is unclear. If quit, move, and a new field are tangled into one gesture, separate them in which path to choose when the next step splits. The feeling that the work no longer proves you matter is the other problem, and it has a page of its own: when a tool makes the work feel pointless.

Is there any point in learning to code anymore

Is there any point in learning to code anymore is the question students and mid-career people ask in the same week, and they are not asking the same thing.

The old bargain was simple. Learn the syntax. Get a junior seat. Spend two years turning small tickets into routine code, and call the repetition training. A large share of that repetition is what the tools now do quickly. A person who learns to code in order to occupy that exact seat is training for a door that is narrower than the advertisements say.

The point that remains is different, and it is still a point.

Literacy. You can read what the tool wrote. You can see the confident mistake. People who cannot read the output have to trust it, and trust is a poor operating system for anything that touches money, safety, or another person's data.

Specification. The scarce skill is knowing what to ask for, what done means, and which constraint actually matters. Typing was never that skill. It was the visible part.

Responsibility. Someone still owns the system when it fails, when a customer is harmed, or when the draft looks plausible and is wrong. Ownership is not a prompt. It is a name on a decision.

A field. Code plus hospitals, logistics, a language, a factory, a classroom, or a body of law is harder to treat as generic than code alone. The field is the part you cannot download over a weekend.

If you already write software, move toward the work the tool is worse at: legacy systems, unclear requirements, integration with the physical world, and the judgment about what not to build. If you do not write software, do not start with a six-month program as a reflex. Spend two weeks building one small thing inside the field you already know, with the tool in the loop, and see whether you can tell a good result from a bad one. That test is cheaper than a credential, and it answers the question the credential pretends to answer.

Learning to code as literacy is rational. Learning to code as a guarantee of a 2015 junior job is not a plan.

What to keep, what to learn, and what to stop

Keep the relationships and the domain knowledge. They compound. A tool does not sit in the meeting where the real constraint is said out loud and then denied in the notes.

Learn the tool well enough that you are not superstitious about it. Use it on a real task from your inventory. Notice where it saves an hour and where it creates two hours of repair. That ratio is your education. A demo on a clean example will not show it to you.

Stop collecting courses as proof of seriousness. A course is a bet when you can name the job task it changes. Otherwise it is a receipt.

Stop assuming the next role should erase the last one. Adjacent is allowed. Andre does not have to become a novelist or a founder. He can become the person who reviews automated replies, designs the escalation, or takes the cases the tool should never touch. That is a smaller story. It is also a job.

If you are early in a career and the whole ladder looks newly unstable, the study question is what you should study when you are still undecided. If the week is flat rather than gone, start with how to find meaning in the work you still have.

A smaller bet than a new identity

At the end of ninety days you should be able to say a plain sentence. "I am staying near this field, and I am being paid to review what the tool gets wrong." Or "I tested a new skill for six weeks, nobody wanted it, and I am returning to the inventory." Or "The money problem is solved for now, and the meaning problem is separate."

That last split matters. A layoff can bruise your sense of what you are for. Do not make the bruise choose the next job by itself. The pattern under the role, the part that stays when the title changes, is who you are when a pattern repeats. If the question has become what any of the work is for, read how to find meaning in life again.

A Meridian Reading is a structured written reading of your patterns and direction. It does not tell you which skill the market will pay for next, and it is not a plan for the layoff. The sample reading shows the shape of the document. Use it as context for a bet you still have to run.