Your first AI project should be small enough to finish.

When you are learning a new way to build software, the project matters as much as the tool. Choose something too large and you end up learning a new stack, a new product, and a new working relationship all at once.

My suggestion is to begin with a problem you already understand. A small utility that checks a sample file. A page that turns a few inputs into a useful checklist. Something with an outcome you can describe in a sentence.

1. Write the finish line before the prompt

For a first exercise, try a local utility that checks a CSV file for missing required fields and reports the row numbers. Use made-up data. Keep accounts, payments, production systems, and deployment out of this first session.

Define “finished” in observable terms: a valid sample passes; a missing field identifies the correct row; an empty file gets an understandable message; the original file stays unchanged. Decide how quoted commas and blank lines should behave. Those details are part of the work.

2. Ask for a plan you can question

Give the assistant the language and environment you want to use. Describe your sample data and acceptance checks. Ask it to list assumptions and propose the smallest implementation before editing files.

Build a local CSV checker in the language this project already uses. It must report missing required values by row and never modify the input. First inspect the project, explain your approach, and identify any unclear requirements. Do not add dependencies or send file contents to a service.

Use only tools and data permitted in your environment. An instruction about data is not a substitute for checking how the assistant itself handles the context you give it. Keep confidential work out of an experiment unless its use is approved.

3. Keep the change reviewable

Start from a clean commit or a separate branch. Ask for one piece at a time. If the assistant proposes an unfamiliar package for a small task, ask why it is needed. If it edits unrelated files, stop and understand the reason before accepting the change.

Read the diff. Run the checker against examples you prepared yourself, including malformed input. A test written from the same mistaken assumption as the implementation can pass quite happily.

4. Close the session with evidence

Record what worked, what failed, what you corrected, and what you still do not understand. Ask the assistant to explain the final code, then see whether you can explain it without its help.

The goal of this first exercise is modest: finish something useful and learn where you need to pay attention. If you spend the whole session inspecting one surprising result, that can still be a worthwhile session.

Next time, change one thing. Try a slightly harder input or a small new requirement. Build confidence from repeated, understandable outcomes.

Thanks for reading.
— Vince