Coding with AI Assistants

Broadly there are two shapes of AI coding help. Chat assistants (ChatGPT, Claude and others) are a conversation: you describe a problem in plain language and they reply with code and an explanation, which you copy into your editor. In-editor assistants (GitHub Copilot most famously) live inside VS Code and suggest code as you type, completing lines and whole functions from the context around your cursor. Both are built on large language models trained on vast amounts of text and code; both are astonishingly fluent and genuinely useful.

They shine at a predictable set of jobs. They are excellent at boilerplate and syntax you forget - the exact spelling of a pandas group-by, how to open a file safely, the shape of a matplotlib chart. They are superb at explaining - paste a traceback or an unfamiliar snippet and ask 'what does this do and why is it failing?' and you get a patient, tailored answer, which makes them a remarkable learning tool. They give you a first draft to react to, which is often easier than a blank page. And they are quick at routine data-wrangling and translating an idea between libraries. For a designer, that covers a huge share of real scripting. Where they get shakier is anything needing correctness you cannot easily check, current API details, or knowledge of your specific project and data - which is exactly where verification comes in. It helps to hold a simple mental model: these tools predict likely text, so they are strongest where the answer is common and well-documented, and weakest where it is niche, recent, or specific to you. That is why they nail a standard pandas operation and stumble on the exact argument a fast-moving plugin API added last month.

The quality of what you get back tracks closely with the quality of what you ask. A vague prompt ('write code to sort rooms') gets a vague, generic answer. A good prompt reads like a clear brief to a capable junior: the task, the inputs and their shape, the desired output, and any constraints. Compare 'sort my rooms' with something specific:

I have a Python list of tuples like
[("living", 24.0), ("kitchen", 12.5)] -- (name, area in sqm).
Write a function that returns the names of rooms over 15 sqm,
sorted largest first. Plain standard library, no pandas.

That prompt gets you usable, on-target code because you removed the guesswork. Give it a real example of your data, say what libraries you want (or want to avoid), and state the edge cases you care about ('some areas may be missing'). If the first answer is close but wrong, do not start over - refine in conversation: 'good, but it crashes when an area is None - handle that' gets a targeted fix. Ask it to explain its own code line by line when you do not follow something; that turns every request into a lesson. And keep requests focused - asking for one well-defined function you can verify beats asking for a whole program you cannot. The skill of describing a problem precisely, it turns out, is the same skill that makes you a better programmer regardless of AI.

Here is the rule that separates the accelerated designer from the endangered one: never use code you have not read and understood. AI models produce text that is plausible, which is not the same as correct. They will confidently invent functions that do not exist, call an API the way it worked three versions ago, get units or edge cases subtly wrong, and present all of it in the same self-assured tone as their best work. This is often called hallucination, and it is not a rare glitch - it is a fundamental property of how these tools work.

So treat every answer as a draft from a fast junior, not gospel. Read each line and ask 'do I understand what this does?' If not, ask the assistant to explain it - or do not use it. Then run it on real data and check the result yourself: does the total match a schedule you totalled by hand? Does it behave on an empty list, a missing value, a room of exactly 15 sqm? A worked verification looks like this:

def big_rooms(rooms):
    return sorted([n for n, a in rooms if a > 15], key=lambda n: -dict(rooms)[n])

test = [("living", 24.0), ("kitchen", 12.5), ("study", 15.0)]
print(big_rooms(test))   # check: is 'study' at exactly 15 in or out?

That one test exposes a decision the AI made silently - whether > 15 excludes the 15 sqm study - that you may or may not have wanted. The habit of writing a tiny check like that, on your real inputs, is your entire defence against confident nonsense. It is also why the fundamentals in this course matter more in the AI era, not less: you cannot verify what you cannot read.

Put the pieces together and the honest picture is neither hype nor doom. AI assistants are a genuine accelerator - for a designer who has the fundamentals. If you can read Python, describe a problem precisely, run a quick test and spot when an answer is wrong, these tools let you work faster, get unstuck instantly, and learn continuously by asking 'why' about every snippet. They are especially kind to designers, because our scripts are usually small and verifiable - exactly the sweet spot where a fast draft plus a quick check wins.

But they do not remove the need to learn, and anyone selling that is wrong. An assistant is a source of confident mistakes for someone who cannot read the answer, and leaning on it without understanding builds a fragile dependence that collapses the moment the code needs debugging - which it always eventually does. There are also real limits to respect: do not paste confidential client data or secrets into a third-party tool without knowing its policy; do not assume its knowledge of a fast-moving library API is current; and remember it knows nothing about your project beyond what you tell it. Used with those eyes open, an AI assistant is one of the best things ever to happen to a self-taught designer-coder. Used as a substitute for understanding, it is a trap wearing a helpful smile. This whole course exists to make you the person who can tell the difference.

The most valuable way a designer can use an AI assistant while still building skill is as a patient tutor, not just a code vending machine. Every answer it gives is a chance to learn something, if you ask. When it hands you a snippet, ask it to explain the parts you do not follow: 'what does the key=lambda bit do here?' or 'why did you use a dictionary instead of a list?' You get a tailored explanation exactly at your level, on the exact code in front of you - a kind of on-demand teaching that no book can match.

Push further and it teaches faster still. Ask for two different approaches to the same problem and to compare their trade-offs - you learn that there is rarely one right answer, and you start to develop taste. Paste your own code and ask 'how would you make this clearer?' or 'what edge cases am I missing?' - a gentle, private code review that sharpens the habits from Lesson 10.1. Ask it to translate an idea between libraries you know and ones you do not, and you learn the new one by seeing it beside the familiar.

The distinction that matters is between leaning and learning. Leaning is pasting code you do not understand because it seems to work; it feels productive and quietly leaves you helpless the moment the code needs fixing. Learning is using the assistant to understand, so that next time you could write it yourself. A simple test keeps you honest: for any snippet you keep, could you re-create it, given time, without the AI? If yes, you have learned. If no, you have borrowed - so ask it to explain until you could. Used this way, an assistant compresses months of learning into weeks, precisely because it removes the friction of finding an explanation while keeping you in the driver's seat. The fundamentals still have to end up in your head; the AI just gets them there faster.