How to Think About Code — AI Coding Beginner | Mastering Coding with AI Day 1 of 5

I’ve built security tools, scrapers, dashboards, and automation scripts using AI coding assistants — and the single biggest skill in all of that work isn’t knowing syntax, it’s knowing how to think about what I want to build. That thinking skill is teachable in one day. The CEH practice exam covers programming concepts in the security domain — after this course you’ll understand those questions differently. And the LLM Hacking Hub is where this course connects to the security tools we build.

What Code Actually Is — The Honest Explanation

Most explanations of code start with syntax — the specific words and symbols used in Python, JavaScript, or whatever language. I think that’s exactly backwards for someone learning to work with AI. So here’s the honest, syntax-free explanation.

Code is a list of instructions written in a language a computer can follow. That’s it. The key word is “instructions.” Not magic. Not thinking. Not intelligence. Instructions. Step 1, then step 2, then step 3.

Your oven has a timer. When you set it to “bake at 180°C for 45 minutes,” the oven follows instructions: heat element to 180°C, monitor temperature, maintain it, count 45 minutes, then beep and stop. You wrote those instructions with a dial, not with Python. But the concept is identical — a specific set of steps to execute in sequence.

Code is just that, written in a formal language the computer can parse without ambiguity. The formal language part is why code seems scary — it has strict rules about punctuation, structure, and naming. A missing comma can break everything. But that strictness exists not to make coding hard for you; it exists because computers have no ability to guess what you meant. They need instructions with zero ambiguity.

Here’s why this matters for AI coding: when you ask an AI to write code, the AI writes those unambiguous instructions on your behalf. Your job isn’t to know the formal language — it’s to know what instructions you need well enough to describe them clearly. That description skill is what I’m building with you this week.

There are hundreds of programming languages. Python, JavaScript, HTML, CSS, SQL, TypeScript, PHP, Go, Rust — they all do the same fundamental thing (give instructions to computers) but with different vocabulary and style. Like how English and Spanish can both describe making a cup of coffee, but the exact words differ. When working with AI, you usually don’t need to choose a language — you describe what you want and tell the AI which language to use, or ask it to recommend one for your use case.

The Only Mental Model You Need: Input → Process → Output

Every program ever written — from the simplest calculator to the most complex AI system — follows the same structure. I’ve worked through hundreds of tools in my security career and never found one that breaks this model. Once you internalise it, every coding conversation you have with AI becomes dramatically clearer.

The model: Input → Process → Output.

Input is what goes into the program. Data the user provides, data loaded from a file, data fetched from the internet, the current time, anything the program receives. An email address typed into a form is input. A password typed at login is input. A file you upload is input. A URL you visit is input.

Process is what the program does with the input. Check the email format. Compare the password to the stored one. Read the file’s contents. Fetch the webpage at that URL. Processing can be simple (check if this number is bigger than 10) or enormously complex (run a machine learning model on an image), but it always happens between receiving input and producing output.

Output is what the program produces. A success or error message. The comparison result. The contents of the file. The webpage’s HTML. A notification. A database record written. Anything the program creates or changes or sends.

Let me make this concrete with the email form my colleague was building:

Input: user types their email address into a box and clicks “Submit”
Process: check if the email format looks valid (has an @ and a domain), save it to a list
Output: show “Thank you, you’re subscribed!” or “Please enter a valid email”

Everything she needed to tell ChatGPT was in those three lines. She didn’t need to know HTML or JavaScript. She needed to clearly describe the input, process, and output. Once she could do that, the AI could write the code. Her job was the what. The AI’s job was the how.

I use this model every single time I start a new coding conversation with AI. Before I type a single word to ChatGPT or Claude, I write out three lines: Input, Process, Output. That discipline alone produces better AI code than any prompt template I’ve ever seen.

Why Vague Instructions Break AI Coding

Here’s the most common reason AI-generated code fails for beginners: the instructions were too vague. Not wrong — vague. And vague instructions to a code-generating AI produce code that technically runs but doesn’t do what you actually wanted.

My colleague’s original prompt was “make me a form where people can enter their email.” That produced code. But it produced just a form box and a button — no validation, no confirmation message, no storage, no styling, no mobile compatibility. The AI did exactly what she asked. She just didn’t ask for enough.

AI coding assistants are extraordinarily literal. They answer the question you asked, not the question you meant to ask. This is the same thing I covered in the prompt engineering course — the model predicts the most probable response to your exact input. If your input is vague, the most probable response is a minimal, generic implementation.

The specificity requirement works at three levels:

Level 1 — What the tool does. Not “a form” but “a form that collects email addresses, validates they have the correct format (contains @ and a domain), and shows a green success message or a red error message depending on whether the email is valid.”

Level 2 — Where and how it runs. “A single HTML file I can open in Chrome without installing anything” is completely different from “a Python web app running on a server” even if the functionality is identical. Always specify the environment.

Level 3 — What it should look like and feel like. “Dark background, amber accent colour, mobile-friendly” produces dramatically different code from an unstyled default. If appearance matters to you, say so explicitly.

The good news: you don’t need to know how to implement any of this. You just need to describe it. The AI knows how to validate email formats. It knows how to show messages in different colours. It knows how to make things mobile-friendly. Your job is to say what you want. Its job is to know how.

What a Bug Actually Is — And Why It’s Never Random

If you’re going to use AI to write code, you’ll encounter bugs. That’s not a failure of AI or a failure of you — it’s a property of software. Even senior developers produce bugs. Bugs are not random, though. Understanding what they actually are changes how you respond to them.

A bug is a gap between what the code does and what you intended it to do. That’s the full definition. No more, no less.

Bugs come from three sources, and knowing which source you’re dealing with completely changes how to fix it.

Source 1 — The code doesn’t match your description. You described what you wanted, but the AI wrote something that does something slightly different. The code is doing what the AI understood — which wasn’t exactly what you meant. Solution: go back and make your description more precise. Don’t ask the AI to “fix the bug” without explaining what the bug actually is.

Source 2 — Your description was internally inconsistent. You asked for something that works one way in Part A and a different way in Part B, and they conflict. The AI picked one interpretation. Solution: re-read your description, find the conflict, resolve it, and give the AI the corrected requirements.

Source 3 — The AI made an error in implementation. Your description was clear, but the AI generated code that has a mistake in the logic. Less common than the first two, but happens. Solution: describe exactly what’s wrong (what did you expect? what actually happened?) and ask the AI to fix the specific problem.

The key insight from all three sources: bugs always have causes, and the cause determines the fix. Randomly asking the AI to “fix it” without identifying the source produces more code that might accidentally work once and fail differently next time.

You Are the Architect, Not the Builder

There’s a useful analogy from construction that I come back to constantly when teaching non-developers to use AI coding assistants.

When a building gets designed and built, there are two distinct roles: the architect, who designs what the building should be — its purpose, its spaces, how it should work, how it should look — and the builders, who physically construct it following the architect’s specifications. The architect doesn’t need to know how to lay bricks or wire electrical systems. They need to know what the building needs to do and be able to specify that clearly enough for builders to execute.

When you use AI to write code, you are the architect. The AI is the builder. The AI can build extraordinary things. It knows dozens of programming languages, thousands of libraries, hundreds of common patterns. But it needs you to specify what to build and why. Without a clear specification, even the most capable builder produces something that doesn’t quite fit the need.

My architectural checklist before any AI coding session:

What does this tool need to do? (The function — in Input → Process → Output form)
Who uses it, and how? (The users — yourself, specific people, the public?)
Where does it need to run? (The environment — browser, phone, server, desktop?)
What does it need to look like? (The style — if it matters)
What shouldn’t it do? (The constraints — security rules, limitations, restrictions)

That last point is the one I see most often missed. When I build security tools, specifying what the tool shouldn’t do is often as important as what it should. “Do not store any user input” or “Do not make external network requests” or “Do not execute any code from user input” — these constraints prevent entire categories of security problem before the code is even written.

Why Understanding Code Makes You Safer Online

I’m a security trainer first. I’ve woven security thinking into this coding course because the two are inseparable — and because people who understand how code works are measurably harder to attack and scam.

Here’s what changes when you understand the Input → Process → Output model from a security perspective.

You recognise when something is trying to be your input. Phishing emails, malicious attachments, social engineering calls — all of these are attacks on human input channels. The attacker is trying to become the input to your mental process. Understanding that you are always in a system — with inputs, a process, and outputs — makes you more aware of what you’re being fed as input.

You understand why your personal data is valuable. Every form you fill out online is input to someone’s process that produces some output they care about. When you know this, “why does this app need my phone number to show me recipes?” becomes a natural question rather than something you just click through.

You can spot when code is doing something unexpected. If you’ve built a simple tool with AI and you understand its Input → Process → Output, you’ll notice if it starts behaving in a way that doesn’t match that model. That noticing instinct is the beginning of security awareness in software.

The vibe coding security risks article covers the specific dangers of generating code without understanding what it does — the exact trap this course helps you sidestep from Day 1. I’ve seen non-technical founders build AI-generated apps with security holes you could drive a truck through, not because AI wrote bad code, but because they had no mental model to evaluate what the code was doing.