التعلّم بالذكاء الاصطناعي دون تفويت التعلّم
في هذا الدرس 11 موضوعات
هذا الدرس متاح حاليًا باللغة الإنجليزية فقط، ولم تُنشر نسخته العربية بعد.
Lesson Overview
An assistant can explain an exception in seconds. That is a real benefit, and also a risk: if you paste the error, copy the fix, and move on, you finish the task and learn nothing. The next bug will cost you the same time, and in an interview or on a team you will not be able to explain your own code.
This lesson gives you a short routine that keeps the learning with you: hypothesis, ask, confirm, and then explain it back. It also covers the safe-use rules: what you must never paste into a chat, and how to clean a stack trace first.
Why this matters: employers expect juniors to use assistants and to be accountable for the result. They also have policies about what may leave the company. Both start with habits you build now.
This lesson builds on "Asking good questions: goal, code, error, attempts" and on the debugging method from BEG-018 (reproduce, isolate, hypothesize, test, fix, verify).
Learning Objectives
By the end of this lesson you will be able to:
- Write a hypothesis about a bug before asking anything.
- Ask an assistant to explain an error or concept rather than to hand over a finished answer.
- Restate an assistant's explanation in your own words, and ask again if you cannot.
- Confirm or reject the answer with the debugger or a small test.
- List what must never be pasted into a chat: passwords, keys, tokens, and personal data.
- Clean a stack trace and a code snippet before sharing, and follow course and employer policies.
Written Explanation
The three-step routine
- My hypothesis. Reproduce the bug, read the stack trace, and write one or two sentences: "I think X happens at line N because Y." Even a wrong guess is valuable, because it shows what you understood and what you did not.
- Ask. Use the four-part question from the last lesson, and ask for an explanation: "Explain why this exception happens and how I could find the cause myself." Avoid "write the fixed code".
- Confirm or reject. Compare the answer with your hypothesis. Then settle it with evidence: the debugger, a print of the suspicious variable, or a small test. Keep what is confirmed, throw away what is not.
Then add the step that makes it learning: explain it back.
Explain it back
Close the chat and, without looking, write down in your own words: what the error means, which line caused it, why, and how the fix prevents it. If you cannot, you have copied rather than learned. Open the chat again and ask a narrower question about the part you could not explain ("Why is the loop's bound the cause?"), or read the matching documentation. This is the same idea as the hand-tracing you practised in BEG-016: you understand a program when you can predict what it does.
Ask for help that teaches
| Instead of | Try |
|---|---|
| "Fix this." | "Explain what this exception means and which variable is involved." |
| "Write the method." | "Here is my attempt. What is wrong with my approach? Do not rewrite it." |
| "Give me the solution." | "Give me a hint, not the answer." |
Asking for hints and reviews keeps you in the driver's seat. When you do accept a code suggestion, type it yourself, run it, and be ready to explain every line.
Confirm with evidence, not agreement
Agreement between you and the assistant is not evidence. Evidence is: the debugger shows the variable is null, a test fails before and passes after, the documentation states the behaviour. You practised the debugger and print-based checks in BEG-018; use them here. If the assistant's answer is wrong or incomplete, note it in your log. That record teaches you where it is weakest.
Safe use: what never to paste
Anything you type into an assistant leaves your computer. OWASP's guidance on LLM risks lists personal data, financial and health records, confidential business information, and security credentials as sensitive, and tells users to avoid submitting sensitive information; it also notes that what you enter might later appear in a model's output. So:
- Never paste passwords, API keys, access tokens, private keys, or connection strings that contain credentials.
- Never paste personal data: real customer names, emails, phone numbers, addresses, ID numbers.
- Never paste confidential company code or data unless your employer's policy explicitly allows that tool for that material. In this course, follow your instructor's rules.
- Check first. Stack traces and logs can contain file paths with your username, URLs with credentials, or data values. Read them before pasting.
Replace sensitive values with obvious placeholders (<PASSWORD>, user@example.com) or invent fake test data. If you pasted a secret by mistake, treat it as exposed: change or revoke it, and tell whoever is responsible for it, because deleting the chat may not be enough.
Policies come first
Employers and schools set rules: which tools are approved, what material may be shared, and whether AI-written code may be submitted. Those rules override this lesson's habits. If a rule is unclear, ask before you paste. Never use personal accounts for company data to get around a rule.
Examples
Example 1: hypothesis first, then ask (simple)
You run this and get a NullPointerException:
public class Ex4 {
public static void main(String[] args) {
String name = null;
System.out.println(name.length());
}
}Exception in thread "main" java.lang.NullPointerException: Cannot invoke "String.length()" because "<local1>" is null
at Ex4.main(Ex4.java:4)Your hypothesis: "Line 4 calls length() on a variable that is null; name was set to null on line 3." (The message says <local1> because the program was compiled without debug names; an IDE build usually shows the variable name.)
Then you ask: "Explain this message. Which variable is null? How do I find where a null comes from in a bigger program?" The answer matches your guess, and it adds a technique (read the line in the trace, then trace the variable backwards). You confirm with the debugger by setting a breakpoint on line 4 and checking name. You explain back: "A method call on null fails; the trace line is where it fails, not where the null was created."
Example 2: cleaning a trace before sharing (practical)
Imagine a database error from a program like the one in BEG-055. The raw text, made up here for illustration, contains a secret:
org.postgresql.util.PSQLException: FATAL: password authentication failed for user "app"
connection: jdbc:postgresql://db.internal.example:5432/library?user=app&password=hunter2
at com.example.Db.connect(Db.java:21)Pasting this leaks a password and an internal host name. Clean it first:
org.postgresql.util.PSQLException: FATAL: password authentication failed for user "<USER>"
connection: jdbc:postgresql://<HOST>:5432/library?user=<USER>&password=<REDACTED>
at com.example.Db.connect(Db.java:21)The useful part for diagnosis (the exception type, the message, and the line) is untouched. Better still, as BEG-055 taught, keep credentials out of code and URLs in the first place by reading them from environment variables. If the real password was ever shown in a place you did not control, change it.
Example 3: explaining back and checking with a test (realistic)
You wrote average and it crashed with / by zero on an empty array. You asked an assistant to explain, and it said: "grades.length is 0 so you divide by zero; add a guard." You explain back: "Integer division by zero throws ArithmeticException. For an empty array the loop adds nothing and the length is 0. I need to decide what an empty array should return." You choose 0, write the guard yourself, and test both cases:
public class Fix {
static int average(int[] grades) {
if (grades.length == 0) return 0;
int sum = 0;
for (int g : grades) sum += g;
return sum / grades.length;
}
public static void main(String[] args) {
System.out.println(average(new int[] {80, 90}));
System.out.println(average(new int[] {}));
}
}85
0The evidence is the run: 85 shows normal input still works, and 0 shows the empty case no longer crashes. Note the choice of 0 is yours: it fits some programs and hides a problem in others. The assistant explained the crash; you made and tested the decision.
Backend Insight
On a real team you are the author of the pull request, whoever drafted the code. Reviewers ask "why is it written this way?", and "the assistant did it" is not an answer. The explain-back habit makes sure you can answer.
Security is part of the job from the start. Credentials in chat windows, tickets, or repositories are among the most common causes of leaks. Many companies approve specific assistants with specific data rules, and some forbid pasting source code into external tools. Learn the policy on your first day and follow it, because breaking it can cost more than any bug.
Common Mistakes
Mistake 1: Asking before trying
Without a hypothesis you cannot tell whether the answer helped or only sounded good. Try for a few minutes first.
Mistake 2: Accepting a rewritten solution you cannot explain
If you cannot explain every line, you do not own it yet. Ask for the reasoning, then retype and test.
Mistake 3: Pasting secrets or personal data
Passwords, keys, tokens, and real customer data stay out of chats. Check traces and logs before pasting.
Mistake 4: Skipping verification because the answer agreed with you
Two guesses agreeing is not proof. Use the debugger, a test, or the documentation.
Exercises
Try each exercise yourself before opening the solutions.
Level A: Foundation
A1. List the three steps of the routine and the step that turns it into learning.
أظهر الحل A1
A1. Hypothesis, ask, confirm or reject with evidence. The step that turns it into learning is explaining the answer back in your own words.
A2. Name three kinds of data you must never paste into a chat.
أظهر الحل A2
A2. Any three of: passwords, API keys or tokens, private keys, connection strings with credentials, real personal data (names, emails, phone numbers, addresses, ID numbers), confidential company data.
A3. What should you do if you accidentally paste an API key?
أظهر الحل A3
A3. Treat it as exposed: revoke or rotate the key, tell the person responsible for it, and do not rely on deleting the chat.
Level B: Application
B1. For each of these, say whether it is safe to paste, unsafe, or safe after cleaning: (a) a stack trace with only class names and line numbers, (b) a log line containing Authorization: Bearer ... followed by a long token, (c) a 10-line method with no secrets (when your policy allows the tool), (d) a spreadsheet of real customer emails.
أظهر الحل B1
B1. (a) Safe, after a quick read to confirm nothing else is in it. (b) Unsafe: the token is a credential; remove it, or replace it with a placeholder, and rotate it if it is real. (c) Safe if no secrets are in it and the policy allows it. (d) Unsafe: real personal data; use made-up rows instead.
B2. Rewrite "Fix this method" as a request that asks for an explanation and a hint rather than a replacement.
أظهر الحل B2
B2. For example: "Here is my method and the exact error. Explain which line fails and why. Give me a hint about what to check, but do not rewrite the method."
B3. The debugger shows that a variable is null at the failing line, but the assistant said the cause was a wrong index. What do you do?
أظهر الحل B3
B3. Trust the evidence: the debugger observation is a fact about your program. Tell the assistant what the debugger showed, and ask it to explain the null case; and note in your log that its first answer was incorrect or incomplete.
Level C: Challenge
C1. An assistant explains an ArrayIndexOutOfBoundsException to you. Without looking, write four sentences: what the message means, which line the trace points to, why it happened in your program, and how your fix prevents it. Explain what you do if you cannot write the fourth sentence.
أظهر الحل C1
C1. For example: "The message says the index was outside the array's length. The trace points to line N in my method. The loop ran one step too far because the bound used <= with length. Using < stops at the last valid index." If you cannot write the fourth sentence, you do not yet understand why the fix works: hand-trace the loop with a variable table for a small array, or ask the assistant a narrower question about that one step.
C2. Your employer's policy says "no company source code in external AI tools". You are stuck on a bug in company code. List three things you can do without breaking the policy.
أظهر الحل C2
C2. For example: use the debugger and tests on your own; reduce the problem to a minimal example using invented data that no longer contains company code and ask about that (if the policy permits it); ask a colleague or mentor; read the official documentation. If you are unsure whether a reduced example is allowed, ask before pasting.
Mini Challenge
Take one small bug (from BEG-018 or your own). Complete the routine on paper in this order: your hypothesis (two sentences), the question you would send (four parts, with any sensitive values replaced by placeholders), the assistant's answer (real or imagined), the evidence that confirms or rejects it, and an explain-back paragraph written without looking at the answer.
Check your work: the hypothesis was written before the question, no secret or personal data appears, the evidence is a debugger observation, a test, or a documentation sentence, and the explain-back is in your own words.
Summary & Next Lesson
Key takeaways
- Use the routine: hypothesis, ask, confirm or reject with evidence, then explain it back.
- Ask for explanations and hints, not finished code to copy.
- Agreement is not evidence; the debugger, tests, and documentation are.
- Never paste passwords, keys, tokens, or personal data; clean traces and logs first.
- Course and employer policies come first. If you leak a secret, rotate it.
Next lesson
The next lesson, "Demo: using an assistant to understand a stack trace, then checking it", walks through the whole routine on one real trace, including an assistant answer that contains an invented method.
Self-check
- What do you write before you ask?
- Why ask for an explanation rather than a fix?
- What counts as evidence for an assistant's answer?
- Name two things that must never be pasted into a chat.
- What is the first thing to do if a real key was pasted?
أظهر الإجابات
- Your own hypothesis: what you think happens, where, and why.
- An explanation builds your understanding and lets you verify; a pasted fix teaches nothing and you may not be able to explain it.
- A debugger observation, a test result, or a documentation statement, not agreement or tone.
- Any two of: passwords, API keys or tokens, personal data, confidential company data.
- Treat it as exposed: revoke or rotate it and tell the person responsible.
References
- OWASP GenAI Security Project, LLM02:2025 Sensitive Information Disclosure. Supports that sensitive information includes personal data, financial and health records, confidential business data, and credentials; that anything entered might appear in later model output; and that users should be taught not to submit sensitive information.
- The routine, the redaction example (the host, user, and password in it are invented), and the
Fixprogram are this course's own material; the Java outputs shown are real, from JDK 21. Advice on rotating an exposed secret is standard practice that I did not verify against a specific source page.
التطبيق
طبّق هذا الدرس بمختبر الوحدة وتمارينها واختبارها.
تعليم الدرس كمكتمل اختياري ويمكنك التراجع عنه في أي وقت. يبقى تقدمك محفوظًا في هذا المتصفح.