3.3Help with code & technical tasks
The essentials in 30 seconds
- Understand first: get the error or code explained before getting anything written; require line-by-line comments.
- Frame it: environment, input, expected output, example — otherwise the code misses the target.
- Test on a copy: never on the real files first; never run what you do not understand.
Running case — Amine and the 200 files to rename
Amine, a project manager in Algiers, must rename site photos with the date for his report. Without knowing how to code, he asks for a script specifying environment, input and output, requires comments in English, gets the doubtful lines explained, then tests on a copy folder with 3 files. On error, he pastes the message and iterates. Only then does he run it on the real files.
This same case runs through the lesson, the diagram, the script and the 48h challenge.
1. A technical translator for everyone
No need to be a developer: AI explains an error message, writes an advanced Excel formula, a simple script (renaming files, extracting data), a query or a macro.
For non-developers, it is a technical translator; for developers, a now-standard accelerator. The safest use remains explanation: paste the full error with context and ask for the meaning, then the fix.
2. Understand before copying, test on a copy
Get things explained before getting them written: understanding > copying. Frame each request (environment, input, output, example) and get the code commented line by line — you must be able to say what it does.
Two safety rules: test on a copy (test folder, never production) and never run code you do not broadly understand. Suggested code must still be checked, especially on edge cases.
🔎 Concrete example — A script without knowing how to code
Amine frames and secures before automating.
“Windows PowerShell script that [task]. Input: [...]. Output: [...].
Comment each line in English, tell me how to run it.”
→ test on a COPY FOLDER (3 files), then the real thing.Outcome: framing decides how correct the code is.
Lesson: pasted error → fix, until it works on the copy.
Section vocabulary
- Error explanation
- Meaning and fix of an error message pasted with its context: the safest use.
Simple example: Amine pastes the script error with what he was doing.
What it is not: pasting the error without stating the environment or the action.
Reflex: always attach the full error + context.
- Framed script request
- Request specifying environment, input, expected output and an example.
Simple example: Amine describes Windows, the photos as input, the naming as output.
What it is not: “make me a script for my files” with no details.
Reflex: write input, output, environment every time.
- Test on a copy
- Trial on test data or a copy, never directly on production.
Simple example: Amine tests on 3 copied files before the 200 real ones.
What it is not: running the rename script on the originals.
Reflex: create the copy folder before any run.
- Minimum understanding
- Being able to say what the code does thanks to line-by-line comments.
Simple example: Amine gets line 3 explained and the name-conflict case.
What it is not: running totally obscure code.
Reflex: get it commented, then question one line.
- Iteration on error
- Debugging loop: paste the error obtained to get the fix.
Simple example: Amine pastes the message and asks for the fix.
What it is not: giving up at the first error or editing at random.
Reflex: paste the exact error at each failure.
In practice — Your first useful script (without knowing how to code)
- Identify a repetitive file task (e.g. renaming photos with the date, merging CSVs).
- Frame it: “Write a PowerShell script for Windows that [task]. Input: [description]. Output: [expected]. Comment each line in English and tell me step by step how to run it.”
- Get it explained to you: “What exactly does line 3 do? What happens if a file is already named that way?”
- Test on a COPY FOLDER with 3 files. On error, paste the message and iterate. Only then: the real files.
Ready-to-say script — asking for a framed, commented script
“Write a PowerShell script for Windows that [task]. Input: [description]. Output: [expected]. Comment each line in English, tell me step by step how to run it and what can go wrong. I will first test it on a copy folder.”
To paste as is; test on a copy and get it explained before running.
Copy-paste template — safe script brief
ENVIRONMENT (Windows / Excel / browser): _______________
INPUT (files / data): _______________
EXPECTED OUTPUT (+ example): _______________
LINE-BY-LINE COMMENTS (yes): _______________
TEST ON COPY (3 files + verdict): _______________Small business / freelancer
Without a developer: start with error explanations and a single file script, tested on a copy.
SME in Algeria
Amine automates renaming site photos and documents the steps for his team.
Office / employee
Internal code: only the company-approved tool; minimal anonymised extract otherwise.
Beginner
First step: get an error message you ran into explained, before any script.
✓ Best practices
- Get things explained before getting them written (understanding > copying).
- Frame it: environment, inputs, outputs, example.
- Always test on a copy before the production files.
✗ Common pitfalls
- Running code you do not broadly understand.
- Running a script directly on the real files.
- Pasting proprietary code into an unapproved tool.
Key takeaways
- Technical AI serves first to UNDERSTAND: errors, inherited formulas, jargon.
- A script request specifies inputs, outputs and environment — otherwise the code misses.
- Test on a copy, always: a failed rename script cannot be undone.
- The “pasted error → fix” loop solves most blockers.
48h challenge — apply tomorrow
Get 1 error or formula explained, then test 1 mini-script on a copy (3 files), without touching the originals.
- I get things explained before getting them written.
- I frame inputs, outputs and environment.
- I test on a copy before the real files.
Frequently asked questions
Is AI-generated code reliable?
For short scripts and classic tasks: very good. Reliability drops with complexity and edge cases — hence tests and re-reading. Professional developers re-read AI code like that of a brilliant junior.
Can I paste my company's internal code to get it debugged?
Same rule as documents: proprietary code → company-approved tool only (pro licences exist for that). A minimal anonymised extract may pass; the code base never.
What is the no. 1 safety rule for a generated script?