Stop competing with AI on typing speed. Build the skills around the code: understanding the problem, breaking it down, debugging, reading unfamiliar systems, judging trade-offs, communicating clearly and owning outcomes. These compound over a career and make AI a multiplier for you.
What people tell me
I paste a problem into an AI tool and it writes a cleaner solution in ten seconds than I could in an hour. It knows more libraries than I do and never forgets syntax. I feel like everything I am practising is something a machine already does better. I want to know what I should actually spend my time on so that I am still valuable in a few years.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- AI is strong at producing code for a well-defined problem. Your value is in defining the problem and checking the answer.
- Debugging, reading large codebases and understanding systems are skills AI assists but does not replace.
- Communication and ownership are career skills, not soft extras. They decide who gets trusted with bigger work.
- Domain knowledge makes you harder to replace than knowledge of any single framework.
- Practise each skill on purpose, with a small weekly habit, rather than hoping it appears.
You are comparing the wrong things
When you say AI codes better than you, you usually mean it produces a correct-looking function faster than you. That is true, and it will stay true. But producing a function was never the whole job. It was the most visible part of the job, which is why it feels like the whole thing when you are learning.
A better comparison is this: who decides which function is needed, notices that the requirement is ambiguous, checks that the output handles the edge cases, fits it into a system with ten other moving parts, and answers for it when it fails? That is still you. The skills I list below are the ones that grow that side of the job.
The skills that keep compounding
| Skill | Why AI does not replace it | How to practise it this month |
|---|---|---|
| Problem framing | AI answers the question you ask. Asking the right one is the hard part. | Before any task, write two sentences: what problem this solves and how you will know it worked. |
| Debugging | Real bugs live in the gap between code, data, configuration and people. | When something breaks, write down your hypothesis before you change anything. |
| Reading code | Most work is changing existing systems, not writing new ones. | Spend thirty minutes a week reading an open-source project and tracing one feature end to end. |
| Trade-off judgement | There is rarely one correct answer, only costs you choose. | For every design decision, write one alternative and why you rejected it. |
| Communication | Teams move at the speed of shared understanding. | Write a clear pull request description for every change, even in personal projects. |
| Ownership | Someone must care whether it actually works for users. | Deploy your projects and watch how real people use them. |
| Domain knowledge | Understanding payments or healthcare rules is not in the code. | Pick an industry that interests you and learn how its money and rules work. |
Debugging is the skill I would bet on most
If I could give a student one skill, it would be calm, systematic debugging. AI can suggest fixes, but it cannot sit inside your production system, notice that the timestamps are in two different time zones, and connect that to a support ticket from last Tuesday. The engineers I trust most are not the fastest coders. They are the ones who can walk into a confusing failure and reduce it to a clear cause.
Practise it like this: when you hit a bug, resist pasting it straight into a chat. Give yourself fifteen minutes to form a hypothesis, test it, and narrow the search. Then use AI to check your reasoning. You will be surprised how quickly your instincts improve.
Communication is a technical skill
A lot of students treat writing and speaking as optional. In real teams, the engineer who can explain a trade-off in three clear sentences often has more influence than the one who wrote the cleverest code. That influence turns into better projects, faster promotions and more trust.
Small habits help: summarise what you learned at the end of each study session in five lines, explain a concept to a friend without jargon, and write a short README for every project that a stranger could follow.
Use AI to grow these skills, not skip them
AI is excellent practice equipment if you use it deliberately:
- Ask it to review your code and explain its reasoning, then decide which suggestions you agree with.
- Ask it to generate a buggy version of a function and find the bug yourself.
- Ask it to play a sceptical reviewer who questions your design.
- Ask it to explain an unfamiliar codebase, then verify the explanation by reading the code.
The rule I follow: AI can do the work, but I must be able to defend the work.
A realistic weekly plan
- Two sessions of building on a real project you intend to deploy.
- One debugging session where you fix something without asking AI for the first fifteen minutes.
- One reading session in a codebase you did not write.
- One writing task: a README, a short design note, or a post explaining something you learned.
- Ten minutes of review at the end of the week: what did you understand this week that you did not understand last week?
If you are still stuck
Read The Habits That Make an Engineer Worth Routing Work Through and How to Use AI as a Companion, Not a Crutch. If you want help choosing where to focus given your own background, join Sefism and, as a member, book a 1:1 session.
Was this answer helpful?
Read next
- The Habits That Make an Engineer Worth Routing Work ThroughEvery team has one or two engineers other people route work through, and what they have in common is not raw technical strength. It is that when something is given to them it comes back, and when it will not, you hear about it early. Fifteen habits that build that reputation, none of which require a title or permission.
- 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.
- 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.
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.