Jump to a section
You do not need to memorize a programming language before your first useful experiment. You do need a clear request and a way to judge the result. Try this approach on one small feature, then use the same pattern as your project grows.
Take this with you
Describe the goal, the existing behavior, the boundaries, and the check. Ask for an explanation you can compare with what the app actually does.
01
Name a result someone can observe
“Build my marketplace” asks the assistant to make many decisions at once. “Display six products with their saved names and prices” gives you a result you can inspect. Explain who uses the feature and why. A category filter helps a shopper narrow a catalog; that purpose tells you to check matching results, no results, and a way back to all products.
02
Use four parts in your request
Start with a goal, explain what already exists, set the boundary of the change, and name how you will check it. Keep unknown details as questions for the assistant to investigate. You do not need to guess a filename or method name to sound technical.
A prompt to try in your project
Goal: let shoppers filter the existing catalog by product name. Context: the catalog already displays products and saved prices. Inspect the current route, template, and model first. Boundary: use the existing stack and change only what search needs. Do not redesign the page or add dependencies. Check: matching products appear, an unmatched query shows a helpful empty state, and clearing the query restores the catalog. Propose a short plan before editing.
Want to see this teaching style before buying?
The free sample turns a vague design request into a change you can check.
Read the free course lesson →03
Read the plan before accepting the change
Look for decisions you can evaluate: is the request still limited to search, are existing prices preserved, and does the plan include the empty result? If the plan introduces a new service, ask what problem requires it. Once the approach is clear, have the assistant implement one step and explain the diff. An explanation helps you review the work; it does not replace running the checks.
04
Use the browser as a learning tool
Try a product name you know exists, a word that should match nothing, and an empty search. Refresh the page. Try the same view on a narrow screen. Ask the assistant to explain what happens between the form, the request, the data query, and the page you see. This is how framework vocabulary starts to attach to behavior you already understand.
- I can describe the feature in one sentence.
- The changed files serve that feature.
- The normal case and the empty case behave as expected.
- I can explain the change before committing it.
05
When it fails, send a useful bug report
Write what you did, what you expected, and what happened instead. Include the relevant error after removing secrets and private data. If repeated fixes are not helping, pause and recover a clean reproduction from the current files. A fresh conversation may help organize the evidence, but it is not a substitute for finding the cause.
06
Practice on a project with a visual target
A prompt template is easier to learn when you have something specific to build. In Build Your First Real App, Northstar gives you a storefront reference and a sequence of lessons: product cards, search, cart, and practice orders. You compare the result with a visual target and a checkpoint. The free sample lesson shows how a vague design request becomes a precise change you can judge.
Build Your First Real App
Turn one good prompt into a project you understand.
Build Northstar one feature at a time with prompts, reference examples, and checkpoints. You’ll learn enough of the software behind each screen to ask a better next question.
- Prompting and reviewing a plan · pp. 10–18
- Software basics and setup · pp. 19–30
- Design, catalog, and interactions · pp. 35–48
120-page PDF + visual kit · $29.99 · one-time purchase
Self-paced reading and building. The kit is a browser prototype; you build the Rails app. Checkout uses practice orders.
Questions you might have
Can a beginner use the prompt above?
Yes. Adapt the goal and context to your project, and ask the assistant to inspect the files before choosing an implementation. Do not claim an existing feature works until you have checked it.
Do longer prompts work better?
Length is not the goal. Include enough context and constraints to make the work reviewable. A focused request with one clear check is often easier to use than a long wish list.
Will the course teach me the software basics too?
Yes. It introduces the basics alongside prompting and a Rails marketplace project, including Git, debugging, and deployment. It is a PDF-based course with a visual reference kit.
