Recently I asked Devin to create anot her session to implement Stripe payments on my side project, and I found very interesting the prompt structure it used. Here’s the “template”
Implement <feature to implement> in <repo (app)>, covering X flows:
A) flow 1…
B) flow 2…
== Repo context ==
List of both technical and code architecture concerns
== Task A: task definition ==
Recommended architecture: …
Required behavior:
1. behavior 1
2. Behavior 2
3. …
== Task B: task definition ==
Recommended architecture: …
Required behavior:
1. behavior 1
2. Behavior 2
3. …
== Engineering requirements ==
* Technical and workflow requirements
* …
* If something genuinely blocks you that only the owner can answer (e.g. …), do not fake it — note it in the PR and message it back clearly.I really like this structure, because even though there are technical parts, it focused more on behavior and user intent rather than explicit technical concerns and concrete “steps”
This is the way I usually prompt too, because I stop caring much about actual implementation, and more into following the correct logic that will let users achieve their goals based on user tasks.
What helps me achieve this is think UX and UI as state machines: events that trigger state transitions and side effects that happens on those transitions. That’s it.
What do you think? What “techniques you use to achieve alignment with your agents and help your users achieve their goals?
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime