Partly. You are learning to assemble and ship, which has value, but not yet to understand and own. Close the gap on purpose: pick the parts you do not understand, trace them, rebuild small pieces by hand, and test yourself by changing and breaking the code.
What people tell me
I have built two or three projects mostly by prompting AI tools. They work and they look good. But if someone asked me how the authentication works, or why the state is managed a certain way, I would struggle to explain. I feel like a fraud when I show these projects, and I am not sure whether I have learned anything real.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Working code you cannot explain is a starting point, not a finished skill.
- List the parts you do not understand and work through them one at a time.
- Change, break and rebuild pieces by hand. That is where understanding forms.
- You should be able to explain every part of a project you put on your CV.
- The feeling of being a fraud is useful information. It tells you exactly what to study.
Be honest about what you have learned so far
You have learned something real. You can take an idea, break it into prompts, assemble the output, and get a working application deployed. That is not nothing. Many people never finish anything at all.
But you have not yet learned to understand and own what you built. In a real team, that is the part that matters, because you will be asked to fix it, extend it, and explain it in code review. So the answer is: you are learning, but you are learning the easier half. The good news is that you already have the perfect material to learn the harder half, because the projects are right in front of you.
Turn your project into a study guide
Open your project and make a list with three columns.
| Part of the project | Can I explain it? | What I need to learn |
|---|---|---|
| Login and sessions | Roughly | How tokens are stored and checked |
| Database models | Yes | |
| API error handling | No | Why some errors return 400 and others 500 |
| State management | No | Why this library, and what it replaces |
Everything marked "no" or "roughly" is your curriculum. You do not need to find a course. You need to work through that list.
How to understand a piece you did not write
For each part on the list:
- Trace it. Follow one request from the button click all the way to the database and back. Write down each file it passes through.
- Explain it in your own words. Two or three sentences per step. Ask AI to check your explanation, not to write it.
- Change it. Make a small modification, like adding a field or changing a rule, without AI. See what breaks.
- Break it on purpose. Remove a line and predict what will happen before you run it. Then run it.
- Rebuild it small. In a separate tiny project, build that one piece from scratch with only the documentation.
When you can do all five, you own that part.
The interview test
A good check is to imagine an engineer sitting next to you, pointing at any file, and asking "why is this here?" If your answer is "the AI put it there", you are not ready to put that project on your CV. If your answer is a reason, even an imperfect one, you are.
It is completely fine to say in conversation, "I used AI to scaffold this, and then I went through and made sure I understood every part." That is an honest and increasingly normal way to build. What is not fine is presenting work you cannot defend.
Change how you build the next project
For your next project, flip the ratio:
- Write the core logic yourself. Use AI for boilerplate, styling and explanations.
- Before accepting any generated block, read it and ask one question about it.
- Keep a short learning log in the README: what you learned, what confused you, what you would change.
You will build more slowly for a few weeks. Then you will build faster than before, because you will stop getting stuck on code you do not understand.
About feeling like a fraud
That feeling is not a verdict on you. It is a signal pointing at exactly the gaps you need to close. The people who should worry are the ones who feel no discomfort at all while shipping code they cannot explain. You noticed, which means you are already thinking like an engineer.
An example: working through authentication
Say authentication is the part you understand least. Here is what working through it looks like in practice:
- Find where the login form submits. Write down the endpoint it calls.
- Open that endpoint. Note where the password is checked, and how. Is it hashed? With what?
- Find where the token or session is created. What is stored in it? How long does it last?
- Find the code that protects other routes. How does it read the token, and what happens if it is missing or expired?
- Now change something: make sessions expire after five minutes. Test it.
- Break something: remove the check on one protected route. Confirm you can now reach it logged out. Put it back.
After this, you will be able to explain your authentication to anyone, and you will spot mistakes in the next AI-generated version immediately.
A self-check for every project on your CV
Ask a friend, or even an AI, to quiz you with questions like these, and answer without looking at the code:
- What happens, step by step, when a user signs up?
- Where is data validated, and what happens if validation fails?
- If this app got a hundred times more users, what would break first?
- What would you change if you rebuilt it today?
If you can answer all four with confidence, the project is yours, however it was first generated.
If you are still stuck
Read How to Use AI as a Companion, Not a Crutch and What to Do When You Are Stuck Learning to Code. If you want someone to go through a project with you and point out what to study first, join Sefism and, as a member, book a 1:1 session.
Was this answer helpful?
Read next
- What to Do When You Are Stuck Learning to CodeThere has never been more good material for learning to program and the failure rate has not improved, which tells you the bottleneck is not access to explanation. It is that watching someone else solve a problem feels exactly like learning and is not. Sixteen heuristics for the first year, mostly about what to do at the point where you are stuck.
- 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.
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.