What teaching can tell us about prompting

When you explain a programming concept, the example you choose does a lot of the work.

“Validate the input” is clear to someone who already knows which inputs are valid. A beginner needs more. Is an empty name allowed? Should spaces count? What happens when the value is missing entirely?

A coding agent can produce a plausible answer to the same vague instruction. It still needs the answers to those questions if you want a particular behavior.

I teach programming, so the connection interests me. Explaining what someone needs to understand and specifying what software needs to do share some useful habits. They also have different goals, and I wouldn’t treat a model as a student.

Explain the distinction the example is meant to teach

Suppose we’re adding a booking form.

“Reject dates in the past” looks like a small requirement. But today’s date might be allowed, and a booking time earlier today might already have passed. The answer also depends on which time zone the booking uses.

A useful example exposes that ambiguity.

We could say that bookings belong to a shop’s local time zone. At 14:00, a booking for 13:00 today is invalid; one for 15:00 is valid. The browser’s own time zone shouldn’t change those results.

Now the agent has a behavior to implement. A person reading the example can also see why comparing date strings alone won’t solve the whole problem.

The drawing shows the shop’s clock beside two requested slots. The expected results make the boundary visible before any implementation is chosen.

Feedback should point to the mismatch

Imagine the first implementation rejects every booking dated today.

“That’s wrong, try again” gives the agent very little new information. I would point to the failed example. At 14:00 in the shop’s time zone, 15:00 today should remain bookable. The current code rejects it because it compares only the calendar date.

That correction explains both the expected result and the place where the implementation differs.

I would then check another case, perhaps a customer whose browser is in a different time zone. Otherwise the next attempt could fix the example by adding a special case while leaving the underlying confusion.

This is also why a passing example doesn’t prove the whole feature works. Examples help us express a rule. We still need to check the other behavior the rule implies.

Give the missing context, then inspect what happens

Longer prompts don’t automatically explain more.

A page of general instructions about writing excellent code might leave the booking time zone unspecified. A few concrete sentences can settle it.

I would provide the business rule, point to the existing code that owns it, and describe how I will check the result. If I don’t know the rule yet, I would ask for the options and decide before requesting an implementation.

The agent can help find these questions. It can read the form and tell me which assumptions the code currently makes. That is useful preparation, especially when the behavior stretches across several files.

But I still have to decide whether those assumptions match the product.

The goals eventually separate

When teaching a person, I care whether they can reason through the next problem themselves. I might leave part of an exercise open so they can practice.

When directing an agent to change production code, I care whether the resulting software meets the agreed requirement. Leaving a critical business rule unstated creates an opportunity for a wrong assumption.

For your next prompt, find one phrase that assumes shared understanding. Replace it with an example of what should happen, and one case that should produce a different result. You will have something concrete to inspect when the agent finishes.

Want me to talk about your product? You can sponsor this site.