Using AI tools is fine and increasingly expected. Being unable to write, debug or explain code without them is a real risk, because interviews, reviews and production incidents test exactly that. Keep the tools, but rebuild the ability to think and code independently first.
What people tell me
I have been programming for a while, but these days an AI assistant writes most of my code. I can read and understand what it produces, yet if someone asks me to write something from a blank file I struggle. On a recent internship project the logic was mine but most of the code came from ChatGPT, and now I feel I did something wrong. I also wonder whether learning to code deeply is even worth it now.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Reading code and writing code are different skills. Recognising a correct answer is not the same as producing one.
- AI raises the value of judgement: knowing whether generated code is correct, secure and maintainable.
- Interviews, code reviews and debugging sessions still test independent thinking, often with no assistant available.
- Use a simple rule: think and attempt first, ask AI when stuck, and never ship code you cannot explain line by line.
- Yes, learning to code properly is still worth it. The work is shifting, not disappearing.
You did not do anything wrong, but pay attention to the signal
Using AI tools to write code is not cheating. Professional engineers use assistants every day, and many companies encourage it. If the logic of your internship project was genuinely yours and you understood what shipped, that is real work.
But the feeling you describe, that you can follow code yet cannot produce it, is worth taking seriously. It is an early warning that a core skill is weakening, and that skill is exactly what gets tested when the tool is not in the room. The good news is that it comes back quickly with a few weeks of deliberate practice.
Why independent coding still matters
| Situation | What it demands | Why AI alone is not enough |
|---|---|---|
| Technical interviews | Solving and explaining a problem live | Many rounds do not allow assistants, and follow-up questions probe understanding |
| Code review | Spotting bugs, security issues and poor design in others' code | You cannot judge what you could not have written |
| Debugging production issues | Reasoning about state, logs and edge cases under pressure | Assistants guess confidently when context is missing |
| Architecture decisions | Choosing trade-offs for a specific system | Generated suggestions are generic unless you steer them |
| Growing to senior roles | Teaching, leading, owning outcomes | Seniority is judgement, not typing speed |
AI makes producing code cheap. That makes the ability to tell good code from plausible-looking code more valuable, not less.
Signs the reliance has gone too far
- You cannot start a function without a prompt.
- You accept suggestions without reading them fully.
- You cannot explain why a generated solution works or what its complexity is.
- Bugs in AI-written code take you much longer to fix than bugs in your own.
- You avoid problems where the assistant is unhelpful.
If three or more sound familiar, it is time to rebuild deliberately.
A four-week rebuild plan
- Week 1: basics without assistance. Turn off inline suggestions for your practice sessions. Spend 30 to 45 minutes a day writing small programs from scratch in your main language: string manipulation, collections, file handling, error handling.
- Week 2: a small project, unassisted. Build something modest, such as a command-line expense tracker or a simple REST API, using documentation only. Let yourself struggle. That struggle is the learning.
- Week 3: debugging on purpose. Take code you or an assistant wrote, introduce bugs, and fix them using a debugger and logs rather than asking for the answer.
- Week 4: reintroduce AI with rules. Use the assistant again, following the workflow below, and compare how much more you understand.
Keep a light version going afterwards: one unassisted session a week is enough to keep the skill alive.
A healthy workflow with AI
- Think first. Write down the approach, data structures and edge cases before prompting.
- Attempt first. Write your own version, even if rough, then ask the assistant to review or improve it.
- Ask for explanations, not only code. "Why does this approach work?" teaches more than "write this for me".
- Read every line before accepting it. If you cannot explain a line, look it up before keeping it.
- Test what it gives you. Generated code often misses edge cases, error handling and security concerns.
- Own the result. Anything you commit is your responsibility, whoever typed it.
How much AI is right for your stage
The right balance depends on where you are in your career.
- Students and interns. Lean heavily towards writing code yourself. This is the stage where fundamentals, debugging instincts and problem-solving habits are formed, and they are hard to build later. Use AI mostly to explain concepts and review your attempts.
- Early-career engineers (first two or three years). Use assistants for boilerplate, tests and unfamiliar syntax, but write core logic yourself and make a habit of explaining every change in your pull requests.
- Experienced engineers. Use AI freely for speed, while keeping regular unassisted practice in your main language and staying sharp on system design and debugging. If you are preparing to change jobs, add several weeks of unassisted problem solving before interviews.
Being honest about AI-assisted work
In interviews and on your CV, describe what you actually did: the problem, the design decisions, how you verified the result. Saying "I used AI tools to speed up implementation, and I designed the data model and reviewed and tested every part" is a strong, honest answer. Claiming you wrote everything alone and then failing to explain it is not.
Is learning to code still worth it?
Yes. The skills that matter are shifting towards problem framing, system understanding, reviewing, testing and communication, and all of them rest on knowing how code works. People who understand fundamentals get more out of AI tools, not less, because they can direct them precisely and catch their mistakes. The engineers at risk are those who can only prompt.
If you are still stuck
Read How to use AI as a companion, not a crutch for a fuller workflow, and The fundamentals worth learning as a software engineer for what to rebuild first. If you want help setting up a plan around your own stack, book a free 1:1 session.
Was this answer helpful?
Read next
- 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.