Probably not completely. Keep the direction, update the method. Audit your plan against what AI now makes cheap, keep the parts built on judgement and fundamentals, and add AI tools to how you work. A full pivot is only worth it if your plan depended entirely on routine, well-specified coding.
What people tell me
I made a plan a couple of years ago: learn a stack, build projects, get a job as a developer. I have followed it reasonably well. Now it feels like the ground has moved, and I keep reading that the plan I made is outdated. I do not know whether to keep going, add AI on top, or throw everything away and start again in a new direction.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Change the method before you change the destination.
- Audit your plan: which parts depend on routine coding, and which depend on judgement, fundamentals and people?
- Skills you built before AI are not wasted. They are what let you check AI output.
- Add AI to your workflow and to one project, rather than restarting from zero.
- Revisit the plan every six months instead of rewriting it every time the news changes.
Start with what has not changed
Before rewriting anything, notice how much of your original plan still holds. Companies still need people who can build and maintain software, understand databases, design APIs, debug production issues, and work well in teams. The fundamentals you learned before AI arrived are exactly what let you judge whether AI output is correct. That is not outdated. That is the foundation everyone else is now scrambling to build.
What has changed is the method. How you write code, how fast you are expected to produce a first version, and how much you are expected to own has shifted. So I usually tell people: keep the destination, update the route.
Audit your plan in one sitting
Take your current plan and sort each part into one of three columns.
| Keep | Update | Drop |
|---|---|---|
| Fundamentals: data structures, HTTP, databases, Git | How you practise coding: now with AI tools, deliberately | Memorising syntax and boilerplate |
| Building and deploying real projects | Project ideas: add one sensible AI feature | Tutorial clones with no users or purpose |
| Learning to debug and read code | Expected pace: first versions faster, more time on quality | Competing on raw typing speed |
| Communication and teamwork | Portfolio story: show judgement, not only features | Ten half-finished courses |
Most people find the "keep" column is the longest. That is reassuring, and it is accurate.
When a bigger change is actually justified
A larger pivot makes sense in a few situations:
- Your plan was built entirely around highly repetitive work, such as converting designs into static pages with no logic, and nothing beyond that.
- You have discovered, independently of AI, that you do not enjoy the work.
- A new direction genuinely excites you and you have tested it with a small project, not just read about it.
If none of these apply, a full restart usually costs you a year and gains you very little.
How to add AI without starting again
- In your workflow: use an AI assistant for boilerplate, tests and explanations. Keep writing the core logic yourself until you are confident.
- In one project: add a feature that genuinely benefits from a model, such as search over documents, summarising user input, or classifying support messages. Measure whether it works.
- In your story: when you talk about your work, explain how you used AI and where you decided not to. That judgement is more impressive than the feature.
Plan in six-month windows
A lot of anxiety comes from treating a career plan as a single bet you must get right. Treat it instead as a series of six-month windows. At the end of each one, ask: what did I learn, what does the market show me now, and what is my next six months? This keeps you responsive without letting every headline knock you off course.
A simple next step this week
Write your current plan on one page. Mark every item keep, update or drop. Pick one item from the update column and act on it this week. That is it. Small, honest adjustments beat dramatic restarts almost every time.
An example of an updated plan
Here is how one plan I reviewed changed, without being thrown away. The original read: "Learn React and Node, build five portfolio projects, apply to frontend roles." The updated version looked like this:
| Original item | Updated item |
|---|---|
| Learn React and Node | Same, but use an AI assistant for boilerplate and write core logic by hand |
| Build five portfolio projects | Build two deep projects, deployed, with real users and tests |
| Apply to frontend roles | Apply to frontend and full-stack roles, and mention AI-assisted workflow honestly |
| Nothing | Add one AI feature to one project, with a small evaluation |
| Nothing | Practise reading unfamiliar codebases once a week |
The destination stayed the same. The route became shorter and more relevant. That is what most plans need.
Questions to ask before any big pivot
If you still feel pulled towards a completely new direction, write down answers to these before acting:
- What exactly do I expect the new direction to give me that my current one does not?
- Have I built even one small thing in that new direction, or only read about it?
- How long would it take me to reach the level I am at now, in the new field?
- Who is doing that job today, and have I asked one of them what the work is really like?
If your answers are vague, the urge to pivot is probably anxiety rather than information. If they are specific and still point elsewhere, the pivot may be right, and you will make it with far more confidence.
What to say when people tell you your plan is outdated
You will hear this from friends, relatives and strangers online. A calm answer helps: "I have looked at it. The fundamentals are the same, and I have adjusted how I learn and what I build to include AI. I review the plan every six months." That is a mature position, and it is usually more thought than the person giving the warning has put in.
If you are still stuck
Read The Fundamentals Worth Learning as a Software Engineer and How to Use AI as a Companion, Not a Crutch. If you want a second pair of eyes on your plan, join Sefism and, as a member, book a 1:1 session.
Was this answer helpful?
Read next
- The Fundamentals Worth Learning as a Software EngineerFrameworks are the fastest moving and least valuable part of what you know. This is the layer underneath: how a computer runs your code, data structures as trade offs, complexity at conversational depth, storage, networks, concurrency, version control, testing as a design tool, and the two skills engineers skip that decide how far they get.
- How to Use AI as a Companion, Not a CrutchOne rule decides whether AI tools make you faster or hollow you out: use them for work you could do yourself but would rather not, and for work you are actively trying to understand, never for work you cannot evaluate. Where they genuinely excel, where they quietly damage your skills, and the verification habits that separate engineers who benefit from those who accumulate debt.
- What Actually Changes in Your First Two Years as an EngineerInterviews test the small part of the job that is easy to test, and the rest is learned on site. Reading code as the main skill, how to ask a question that costs nothing, why small shipped changes beat large ones in progress, using code review as the fastest teaching you will get, and the four things that actually get people promoted, three of which are not about writing code.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open to X and Instagram followers and university students. Prefer to talk? A free call works too.