You are not becoming a software engineer. You are building the small internal thing nobody was ever going to prioritise: a calculator, a tracker, a form that cleans up messy input, a page that turns a spreadsheet into something readable.
Write the spec before you generate anything
The single biggest difference between a tool you use for a year and one you abandon in an hour is a spec written first. It does not need to be long:
- What goes in, and in what form.
- What comes out, and who reads it.
- The rules, including the awkward ones.
- What should happen when something is missing or wrong.
Half a page is plenty. Paste it as the first message rather than describing the tool a feature at a time — piecemeal requests produce piecemeal software.
Give the assistant the right context
Most bad generated code comes from an assistant guessing at things you never told it: where the data comes from, what the fields are called, who can see what. Paste a real sample of your input. Name the fields. Say explicitly if something is confidential.
Read what comes back
You do not have to understand every line, but you do have to understand the parts that matter:
- Anything touching passwords, payments or personal data — ask for a plain-language explanation and don't ship what you can't explain to a colleague.
- Where the data is stored and who can reach it.
- What happens on bad input.
Explain, in plain English and without code, what this tool does with the information people type into it: where it is stored, who can read it, and what happens if someone submits something unexpected.
Try this today
Write a one-paragraph spec for a tool you wish existed in your job — inputs, outputs, rules, and what happens when something is missing.