A few years ago, if you wanted to automate a spreadsheet task, build a simple web tool, or write a script that processed data, you had two options: learn to code, or find someone who could.
That's genuinely different now. AI can write functional code for a surprising range of tasks, and it can do it in response to plain English descriptions. People who have never touched a terminal are building things they couldn't have a year ago.
But "AI can write code" is not the same as "AI reliably writes code that works for your specific situation." That gap — between the promise and the reality — is almost entirely explained by how people prompt.
This is what I've learned about prompting for code, both as someone who writes code and as someone who has watched a lot of non-developers try to use AI to do it.
The Most Important Rule: Context Is Everything
Code doesn't exist in a vacuum. A Python script for a Mac running Python 3.11 with certain libraries installed is different from the same script on a Windows machine with Python 3.9. A JavaScript function that works in a browser is different from one that runs in Node.js. A SQL query that works in PostgreSQL doesn't necessarily work in MySQL.
When you ask an AI to "write code to do X" without specifying the environment, it makes assumptions. Sometimes those assumptions match your situation. Often they don't.
Before you write the task, specify:
- Language (Python, JavaScript, SQL, etc.)
- Version, if relevant (Python 3.11, Node 18, etc.)
- Environment (Does this run in a browser? On a server? In a spreadsheet app like Google Sheets or Excel?)
- Libraries or frameworks you're already using (if any)
- What you already have (What's the input? What files, databases, APIs are involved?)
Here's the difference:
Bad:
"Write code to send an email."
Better:
"Write a Python 3.11 script that sends an email using Gmail's SMTP server. I want to pass in the recipient address, subject, and body as variables. I'm running this on a Mac. Show me how to handle the Gmail app password too."
One of these will give you something you can actually run. The other will give you a template you have to figure out yourself.
Describe the Outcome, Not Just the Task
This is counterintuitive for non-developers: focus on what you want the code to accomplish, not the steps you think it should take.
Most non-developers describe the implementation they imagine:
"Use a for loop to go through each row..."
But you probably don't know if a for loop is the right approach. Experienced developers often avoid explicit loops in favor of vectorized operations, list comprehensions, or built-in functions that are faster and cleaner.
Describe the outcome instead:
"I have a CSV file with customer records. Each row has a name, email, and date of last purchase. I want to filter it down to only customers who haven't purchased in more than 90 days, and save that filtered list to a new CSV file."
That's the outcome. The model can choose the best implementation.
The exception: if you have a specific constraint (you need it to work without any imported libraries, you need it to run in Excel VBA, etc.), say that explicitly.
Share the Actual Data Structure
One of the fastest ways to get better code output is to show the AI what your data actually looks like.
Don't say: "I have a JSON file with customer data."
Say:
Here's what my JSON file looks like (a small sample):
[
{
"id": "C001",
"name": "Sarah Chen",
"email": "sarah@example.com",
"purchases": [
{"date": "2025-10-14", "amount": 89.99},
{"date": "2025-08-03", "amount": 134.50}
]
}
]
I want to calculate the total amount spent by each customer across all purchases.
The model now knows the exact field names, nesting structure, and data types. The code it writes will match your actual data instead of guessing.
This applies to database schemas, spreadsheet column names, API response formats — anything with structure. Show it the structure.
Ask It to Explain What It Wrote
If you're not a developer, don't just copy-paste code you don't understand. Ask the model to explain it.
Now explain what this code does, step by step, in plain English. I'm not a developer — focus on what each section accomplishes, not the technical syntax.
This has two benefits: it helps you understand what you're running (important for debugging later), and it often catches when the model made an assumption that doesn't match your situation.
Also ask: "Is there anything that could go wrong with this, or edge cases I should know about?"
Good code is defensive. AI-generated code sometimes isn't. Asking explicitly about failure cases tends to surface important gaps.
When It Doesn't Work: The Debugging Prompt
The most demoralizing AI coding experience is getting code that doesn't work and not knowing what to do with it. A lot of non-developers hit an error, paste it back into the chat, and get revised code that also doesn't work. Repeat until frustration.
Here's a more structured approach:
This code isn't working. Here's the error I'm getting:
[paste the exact error message]
Here's the code that produced it:
[paste the code]
Here's the relevant context:
- I'm running this on [Mac/Windows/Linux]
- Python version: [run python --version in your terminal]
- The input data looks like: [brief description or sample]
What's causing this error, and how do I fix it?
The specific version and environment details aren't just formality — errors often have environment-specific causes. A "ModuleNotFoundError" on Python 3.9 might need a different fix than the same error on Python 3.12.
And paste the exact error, not a paraphrase. Error messages contain specific information the model needs.
Ask for the Test Too
This is something developers do that non-developers don't think about: testing.
When you get code that seems to work, ask:
"How do I verify this is working correctly? Give me 3 simple test cases I can run to confirm it's doing what I expect."
This is especially important if the code processes or transforms data. Something can appear to run successfully — no errors — while quietly producing wrong output. Test cases catch that.
The "Build on It" Approach
Trying to get a complete, complex system in one prompt almost never works. The code is too long for the model to maintain coherence, there are too many decisions to make at once, and you can't catch problems early.
Build incrementally instead.
Start with the core function:
"Write a Python script that reads a CSV and prints the first 10 rows."
Make sure that works. Then add to it:
"Now modify it to filter for rows where the value in the 'status' column is 'active'."
Then add more:
"Now add a second step that exports the filtered results to a new file called 'active_customers.csv'."
This incremental approach keeps each step testable and makes debugging much easier. When something breaks, you know exactly which addition caused it.
What AI Is Genuinely Bad At (for coding)
Fair warning on the failure modes:
Long, complex programs: The longer the code gets, the more likely the model is to introduce subtle bugs or inconsistencies. Break things into functions. Ask for one piece at a time.
Integrating with specific internal systems: AI doesn't know your company's internal APIs, databases, or custom libraries. It can help you write the code, but you'll need to tell it exactly how those systems work.
Performance optimization: AI can write code that works, but it won't necessarily write code that's fast. If you're processing millions of rows or need millisecond response times, you probably need a developer to review what AI generates.
Security-sensitive code: Authentication flows, password handling, encryption — these areas have subtle failure modes that can create real vulnerabilities. Get a human to review.
The Bottom Line
The skills that make you good at prompting generally — specificity, context, clear success criteria, iterative refinement — all apply to coding prompts. The additional layer for code is environment awareness: language, version, libraries, data structure.
Provide those, ask for explanations, test what you get, and build incrementally. That's the difference between "AI can't help me with this" and "AI saved me three hours."
The Intermediate Track covers prompt chaining and structured generation, both of which are particularly useful for more complex coding workflows.