How to learn DSA with AI without letting it write your code

You have been stuck on a dynamic programming problem for forty minutes. You paste it into a chatbot, it hands back twenty lines of code, you submit, and the judge says Accepted. The next problem is the same idea wearing a different story, and you are stuck again — from the beginning.

That is the trap when you try to learn DSA with AI: it is so good at producing code that it lets you skip the only part that transfers. This guide is about using AI the other way round — for the idea, never for the implementation.

Why don't copied solutions transfer?

A contest problem or an interview question almost never asks you to implement a known algorithm. It asks you to recognise which idea applies to something that looks like no problem you have seen. The code is the last and easiest step; the recognition is the skill.

A copied solution hands you the last step and skips the recognition entirely. You end up with a folder of Accepted submissions and no way to start the next one. The fix is not to avoid AI. It is to be strict about what you ask it for.

Learn the invariant, not the implementation

Take binary search. Everyone can write it, and almost everyone has shipped an off-by-one bug in it. The bug does not come from forgetting the code. It comes from not holding the invariant: the answer, if it exists, is always inside [lo, hi], and every step must shrink that range while keeping it true.

That sentence is what you want AI for. In Porphy you highlight a line like that and the voice tutor explains it out loud while drawing the array on a whiteboard — lo and hi as pointers, the middle probe, half the list crossed out at every step. A sorted list of a million items takes about twenty checks, and once you have watched the halving drawn you never need to memorise that number again.

Every DSA topic has a sentence like that. A queue is why BFS finds shortest paths in an unweighted graph. A DP state is a question small enough to answer once and reuse. A heap is a promise about the top element and nothing else. Learn those sentences and the code nearly writes itself.

A DSA roadmap, one course at a time

Porphy does not ship a fixed DSA syllabus. It researches whatever topic you give it on the live web and writes a course from what it finds, with the sources for every part — which makes it easy to walk a roadmap one topic at a time. A sensible order:

• Complexity: Big-O, and why an O(n²) solution times out at n = 10⁵.
• Arrays and strings: two pointers, sliding window, prefix sums.
• Sorting and binary search — including binary search on the answer.
• Stacks, queues and hash maps.
• Recursion and backtracking.
• Trees: traversals, binary search trees, heaps.
• Graphs: BFS, DFS, topological sort, Dijkstra, union-find.
• Greedy algorithms, and how to tell when greedy is safe.
• Dynamic programming: states, transitions, memoization versus tabulation.

A 5–7 part standard course suits most of these; graphs and dynamic programming are really several topics each, and earn an 8–12 part deep dive. Tell the intake what you already know — 'I can do BFS but not Dijkstra' — so the course starts at your gap instead of at arrays.

The explain-back test

The quickest way to find out whether you understand an algorithm is to explain why it works to someone who keeps asking 'why?'. The voice tutor can play that part: ask it to let you explain, and it will tell you what you left out.

Try it on this one: why does Dijkstra's algorithm fail when an edge has a negative weight? If your answer says that Dijkstra finalises a node the moment it is popped, on the assumption that no later path can be shorter, you understand it. If your answer is 'it just doesn't work with negatives', you have memorised a fact about it — which is exactly the gap the comprehension score on the knowledge map exists to catch.

DSA in Bangla, with the terms interviews use

Much of the good DSA teaching in Bangla lives in long videos, which are hard to search and impossible to ask a question of. Porphy explains in Bangla or English, and in Bangla it keeps the technical vocabulary in English — time complexity, recursion, memoization, adjacency list — because that is the vocabulary of your code, the judge's editorial and every interview you will sit.

binary search-এ প্রতি step-এ অর্ধেক list বাদ যায় — তাই দশ লক্ষ item-এও লাগে প্রায় বিশটা check।

Studying a university DSA course

If you are taking data structures or algorithms as a CSE course, upload the lecture slides as a PDF. Every tool then works on your lecturer's own material: highlight a line of pseudocode for the tutor, generate MCQs on the course's exact definitions, and map how its topics depend on each other. The PDF needs selectable text — a scanned handout will not read. The engineering version of this method goes into more detail.

What Porphy will not do for your DSA

• It does not run, test or judge your code. Solve problems on Codeforces, LeetCode, AtCoder or CSES; the judge is the only thing that tells you a solution is actually correct.
• It is not a problem archive and it does not host contests.
• It can be wrong, especially about edge cases. When an explanation and the judge disagree, the judge wins.
• It will not do the reps for you. Pattern recognition in DSA comes from hundreds of problems attempted honestly — AI shortens how long you stay stuck on each one, not how many you need to solve.

How to learn DSA with AI, one stuck problem at a time

• Attempt it for 30–45 minutes on paper first. Being stuck is where the learning happens.
• When you ask for help, ask for the idea — 'what property of this problem should I be looking at?' — never the code.
• If the idea is a topic you have not learned yet, build a course on it before going back to the problem.
• Write the solution yourself and submit it to the judge.
• Afterwards, explain the idea back to the tutor. If you cannot say why your solution works, you got lucky — and the next problem will find out.