What It Is Good At Here
This subject plays to an assistant's strengths. The material is stable, heavily documented, and full of jargon that means something precise, all of which it handles well.
Explaining a file you already have
You can paste a package.json and ask what each field does. The file is right there, so there is nothing to invent, and the answer is checkable against the file itself.
Decoding an error message
You can paste the whole error, including the lines above and below. Error text is distinctive, and an assistant will usually name the cause faster than a search engine.
Translating vocabulary
Inquiries about what a term means in this specific context, and how it differs from a similar term, are reliably useful.
Reading somebody else's project
Handing it an unfamiliar package.json and asking what the project does and how to run it is faster than reconstructing it yourself.
Here is my package.json. Go through it field by field and tell me
what each one controls. If any field is doing nothing useful for a
static site, say so and explain why.set up my projectThe difference is whether the answer can be checked. The first prompt hands over a file and asks for a reading of it, so every claim can be verified against the file. The second asks the assistant to invent something, and leaves you no way to tell a good answer from a bad one.
The Failure That Is A Security Problem
A note from Grace Hopper
An assistant asked for an install command will sometimes produce a package name that does not exist. The name is plausible, formed from words that fit the task, and delivered with the same confidence as a correct one.
You will not always get an error message. Attackers watch for names that assistants invent repeatedly, then publish real packages under those names. The install succeeds, and what it installs is code written specifically to be found this way. Verify a package name against the registry before you run the command, every time.
The check takes fifteen seconds. You can search the exact name on npmjs.com and read three things: the weekly download count, the date of the last publish, and whether the repository link goes anywhere real. If the assistant called a package standard while the registry shows four downloads a week and a first publish last month, you will want to stop there.
Before I install this, confirm the package name character by
character against the npm registry, and tell me its weekly download
count and the date of its most recent publish. If you cannot verify
those, say so rather than guessing.You must check the answer yourself anyway. Asking is worth it because it makes the assistant state the claim out in the open rather than burying it inside a command.
The Other Failures, Which Are Only Annoying
Advice from an older era
Training data is full of years of accumulated tutorials. An assistant will suggest tools and patterns that were standard in 2019 and are not now, with no signal that the answer has a date on it.
Reaching for a package too fast
Asked how to do something, it tends to answer with a dependency. Node and the browser have grown a lot of built-in capability, and the built-in answer is usually better because it adds nothing to install.
Suggesting global installs
npm install -g appears constantly in older documentation. It makes a project unbuildable on anyone else's machine, and a project-local devDependency is almost always what was meant.
Inventing configuration options
Config file keys are guessed the same way package names are. A key that does nothing produces no error, so this failure is silent.
Confident wrong version numbers
Version numbers in a suggested package.json are frequently made up. You can let npm write them by running an install rather than typing them in.
Agreeing with you
If you push back on a correct answer, the assistant will often fold and agree with you instead. This agreement is worth nothing because it happens whether or not you were right.
A Working Habit
While the material is still new, you can let the assistant do the reading and do the writing yourself.
- Run the command yourself. You can run the command yourself so npm writes the version numbers and the lock file, rather than typing them from the assistant's output.
- Hand it the result. You can hand it the result and ask it to explain what changed and why. This ensures every claim has a file behind it.
- Ask what you would have gotten wrong. You can ask what you would have gotten wrong. The assistant answers this one well because it reads your file rather than generating a new one.
- Verify anything that gets installed. You must verify anything that gets installed by checking package names against the registry before running the command.
- Keep the explanation, discard the code you cannot read. It is best to keep the explanation but discard the code you cannot read. Code you cannot explain is code you cannot debug at two in the morning, and this course is about being able to do so.
🟠A sign that you have gone too fast
The project runs, but it is built out of commands you could not repeat from memory and files you have not read. That works until something breaks, and then you have nothing to reason from.
The fix is not to stop using the assistant. Your goal is to be able to say, for every file in the project, what it is and why it is there.
Questions Worth Asking It
"Walk through my package.json field by field."
Checkable, specific, and it surfaces the fields npm init wrote that are doing nothing.
"Here is the full error. What is it telling me?"
Paste all of it. The useful line is often several above the one that looks important.
"Is there a way to do this without adding a dependency?"
This is frequently possible, but the assistant will not volunteer that unless asked.
"How would I check this myself?"
This question turns a single answer into a method you can use again, even on the days the answer is wrong.
"What is the current way to do this, and what changed?"
This prompt encourages the assistant to notice its own age, which it will not do otherwise.