Published / updated29 Aug 2026

AI as a Learning Partner

Before you start

You need: some programming (Track 03 or 13) — enough to judge whether an answer is right.

Take this track alongside the others, not before them. AI amplifies whatever practice you already have.

Time: about 45 minutes.

Learning objective

Use an AI assistant to accelerate learning while keeping the understanding that makes you employable.

Topics

• What these tools are
• What they are good and bad at
• The dependency trap
• Learning prompts versus answer prompts
• Verifying what you are told
• Hallucination
• Using AI to explain existing code
• What to learn without AI

What these tools are

Tool	Form
Claude	Chat, and Claude Code in the terminal — reads and edits a whole repository
GitHub Copilot	Inline completion inside the editor
Codex / ChatGPT	Chat, plus editor integrations
Cursor, Windsurf	Editors built around AI

They differ in interface. The skill of working with them is the same, and it transfers: describe context accurately, ask precisely, verify what comes back.

They predict likely text. That is a genuinely useful thing for code, because code is highly patterned — and it is also why a confident, wrong answer looks identical to a confident, right one.

Good and bad at

Strong	Weak
Explaining unfamiliar code	Knowing your codebase without being shown
Boilerplate — DTOs, mappers, CRUD	Novel algorithms
Syntax in a language you know less well	Anything after its training cutoff
Translating between languages	Your business rules
Writing tests for existing behaviour	Knowing what is actually correct
Suggesting causes for an error	Debugging without evidence
Reviewing for common mistakes	Judging architecture for your constraints
Documentation and commit messages	Knowing what your team decided last month

The pattern: strong on the general, weak on the specific. It knows ASP.NET Core middleware ordering. It does not know that your Student.Status enum has a Transferred value that must be excluded from fee reports, unless you tell it.

Everything unique to your system must come from you. That is what makes context the central skill in this track.

The dependency trap

Week 1:   AI writes it, you read it, you understand it        — learning
Week 4:   AI writes it, you skim it, it works                 — drifting
Week 12:  AI writes it, you paste it, you cannot explain it   — dependent

The trap is that weeks 4 and 12 feel more productive than week 1. Output goes up while understanding goes down, and the gap does not show until something breaks that the AI cannot fix — or until an interview.

Honest self-tests:

• Can you write a for loop, a class and a LINQ query without help?
• Can you explain every line the AI just produced?
• Can you debug code you did not write?
• Could you build a small feature with the network off?

If any answer is no, do that thing manually until it is yes.

The floor to protect: language fundamentals, reading a stack trace, using a debugger, reading SQL, and knowing what your code should do. Those are what let you tell a good AI answer from a plausible one — and without them, AI makes you fast at producing code you cannot defend.

Learning prompts versus answer prompts

Answer prompt:

Write a C# method that calculates a student's total fees.

You get code. You learn nothing.

Learning prompts:

I'm writing a method to calculate a student's total fees from TotalFees,
DiscountAmount and their FeePayment rows. Here's my attempt:

[your code]

Don't rewrite it. Tell me what's wrong with it and why, and point out any
edge case I've missed. I want to fix it myself.

Explain why this LINQ query runs 800 SQL statements instead of one.
Explain the mechanism, not just the fix.

I think EF Core change tracking is why my update isn't saving.
Am I right? If not, what actually happens?

Quiz me on C# collections. Ask one question at a time, wait for my answer,
and tell me what I got wrong before the next one.

"Don't give me the code, tell me what's wrong with mine" is the single highest-value prompt in this article. It preserves the part where you learn — and you still get the answer.

Ask "why" after every answer. An explanation you can restate is knowledge; code you pasted is not.

Ask for the trade-off, not the recommendation. "What are the trade-offs between Dapper and EF Core for this reporting query?" teaches you the axis. "Which should I use?" gives you an opinion you cannot defend in review.

Verifying

Everything an AI tells you is a hypothesis until you check it.

Claim	How to verify
A method exists	Look it up in the official docs
Code works	Run it
A query is correct	Run it in SSMS against real data
A package exists	Search NuGet or npm
A configuration is right	Check the official docs, not a blog
A performance claim	Measure it

The cost of verifying is minutes. The cost of not verifying is a bug in production you cannot explain.

Priority by risk:

Risk	Verification
Authentication, authorisation, payments	Read every line, test the negative cases
Database schema changes	Review, test on a copy, plan the rollback
Anything with SchoolId	Confirm it comes from the token
Business logic	Test the edge cases yourself
Boilerplate DTOs	Skim
Test data, comments	Light

Hallucination

A model can produce a method, a package or a configuration key that does not exist, in fluent and confident prose.

// Does not exist
students.WhereNotNull()
student.ValidateRollNumber()
services.AddSchoolPortalDefaults()

{ "Logging": { "EnableDetailedDatabaseErrors": true } }

A compile error is the harmless case. The dangerous case is code that compiles and is subtly wrong:

// Compiles, runs, and counts absent students as failed
if (result.MarksObtained >= subject.PassingMarks) { return "Pass"; }
if (result.IsAbsent) { return "Absent"; }
return "Fail";

Nothing about that looks wrong. It produces incorrect report cards.

Signals to check harder:

• A method name that is exactly what you wished for
• A package you have never heard of
• Version-specific configuration
• A confident answer about something released recently
• Anything about your own codebase you did not paste in

Ask directly: "Are you confident this API exists in .NET 9? What should I check?" A good model will flag its own uncertainty when asked — but you have to ask.

Explaining existing code

This is where AI is most reliably useful and least risky, because you can verify the explanation against the code in front of you.

Here's a VB.NET module from a legacy system. Explain what it does,
step by step, and list anything that looks like a bug.

[paste code]

What does this stored procedure do? I'm particularly unsure about
the CTE in the middle.

This regex validates roll numbers. Explain each part.

Trace what happens when a user calls POST /api/students in this controller.
Which middleware runs, in what order?

Explanation carries almost no risk, because the code exists and the explanation either matches it or does not. And a wrong explanation of code you can read is a wrong explanation you can catch.

This is the fastest way into an unfamiliar codebase, and the most defensible use of AI in your first weeks on a team.

What to learn without AI

Do these manually until they are automatic:

Skill	Why
Language fundamentals	You cannot review what you cannot read
Reading errors and stack traces	AI needs the error; you must find it
Using a debugger	Evidence beats guessing, AI or not
Reading SQL	To know whether a generated query is right
Git	Recovery is not something to improvise
Knowing the requirement	AI cannot know what correct means

Interviews test these directly, usually without AI available. So does the first production incident.

A reasonable rule while learning: attempt it yourself first, then ask. You keep the learning and still get the answer — and the attempt is what makes the answer make sense.

Errors you will hit

The mistake	Consequence
Asking for the answer instead of a critique	You get code and learn nothing
Trusting a confident answer about your codebase	It has never seen your code
Not checking a method or package exists	A hallucination that compiles is worse than one that does not
Same scrutiny for auth code as for a DTO	The risky code gets the same glance as the trivial code
Skipping fundamentals because AI covers them	You cannot tell a good answer from a plausible one

Confidence in an AI answer correlates with fluency, not accuracy.

Common mistakes

• Pasting code you cannot explain
• Asking for the answer instead of a critique of your attempt
• Trusting a confident answer about your own codebase
• Not checking that a method or package exists
• Same verification effort for auth code as for a DTO
• Skipping fundamentals because AI covers them
• Never asking "why"
• Assuming the AI knows what your business rules are

Practice

The course exercise is use AI to explain, not to write.

1. Write a method yourself, then ask for a critique with "don't rewrite it".
2. Ask for the same method to be written for you. Compare what you learned from each.
3. Ask "why" three times in a row on one answer. Note where the explanation stops being useful.
4. Ask an AI to quiz you on C# collections, one question at a time.
5. Paste an unfamiliar piece of legacy code and ask for a step-by-step explanation. Verify it against the code.
6. Ask for a method that does not exist — something like List.WhereNotNull() — and see what comes back.
7. Ask for a configuration key for a very recent framework version. Verify it in the official docs.
8. Ask for the grading logic for exam results. Check whether the absent case is handled first.
9. Ask for trade-offs between two approaches rather than a recommendation. Then defend one choice.
10. Ask for an explanation of a stored procedure and check every claim against the SQL.
11. Turn off AI for one full day and build a small feature. Note what you reached for and could not use.
12. Take five AI answers and rank them by verification effort using the risk table.

Exercise 11 is the honest test. Whatever you struggled with is what to practise manually.

You can now

• Use AI to learn rather than to avoid learning
• Ask for a critique of your attempt instead of an answer
• Verify claims in proportion to their risk
• Recognise a hallucination that compiles
• Say what you must be able to do without AI

Review questions

1. What are these tools reliably strong at, and what must always come from you?
2. Why does the dependency trap feel like productivity?
3. What makes a hallucination that compiles more dangerous than one that does not?
4. Why is explaining existing code the lowest-risk use?

Next: Context and prompting