Prompt engineering is software engineering with a fuzzier compiler

My title says "Prompt Software Engineer" because that is how I build now. I design the system, then I write precise instructions for an AI model to help implement parts of it, then I review and test what comes back. That is how I built CV Spark. The prompt is not magic. It is a spec.

1. State the constraint, not just the goal

"Make the templates look different" gives you fifty colour swaps. "Each template must use a different layout enum and a different skill style, and no two may share both" gives you real variety. The constraint is where the design lives.

2. Give the model the real names

Paste the actual class and field names. A model guessing p['title'] when your data uses p['name'] creates exactly the bug I once had to fix across thirty templates. Real identifiers in, fewer silent mismatches out.

3. Ask for the boring cases first

Empty lists, very long names, right-to-left text, a résumé with no photo. I list these in the prompt before asking for the happy path. The output gets more defensive and I review less.

4. Review like a teammate wrote it

Generated code goes through the same checks as anything else: run it, read the diff, test on a real device. When something is wrong, I fix the prompt as well as the code, so the next request starts better.

A good prompt reads like a good ticket: what, why, the edges, and how you'll know it's done.

5. Keep a prompt log

For each feature I keep the prompt that worked and a line about why. Months later it is the best documentation of why the code looks the way it does.