Prompts as Programs
I write prompts the way I write code: inputs, outputs, failure cases. Notes from Sithu Nyein on prompt engineering for agents that can spend money.
For a while I treated prompts like chat. Ask, revise, hope, repeat.
That works for demos. It falls apart when an agent has to make a decision you would trust with money, a deploy, or a user-facing answer.
The shift for me was simple. I stopped writing prompts as messages and started writing them as programs.
The contract model
When I write a function, I care about four things: what goes in, what comes out, how the body bridges them, and what happens on failure.
A production prompt needs the same shape.
The input type is what the caller is allowed to pass. The output type is the exact shape I expect back, whether that is JSON, a short verdict, or a refusal. The body is the instructions and examples. The failure handling is what the model should do when the input is messy, hostile, or incomplete.
If those four pieces are missing, I do not have a prompt. I have a wish.
What the Google prompting course actually changed
The useful lesson was not a magic template. It was a reading habit.
I read my own prompt as if I were a smart, literal intern who has never met me. Where would that person choose differently than I intended? That is the bug.
Then I read it as if I were trying to break it. Where can user text override the rules? Where can a new role sneak in? Those holes show up in production eventually. Better to close them on day one.
A real example from my work
I use a review-style prompt in agent work where the model looks at a change and decides whether a human should review it.
The current version has a short role, a strict input schema, a strict output schema, a few labeled examples, an explicit refuse list, and a final reminder that schema drift counts as failure. It is not elegant. It is consistent.
The first version was one paragraph and failed often. The later version fails much less on my own tests. The model did not magically get wiser. I got stricter about the contract.
Failure modes I keep rediscovering
Conflicting instructions are quiet killers. "Be concise" and "always give three examples" in the same prompt will fight each other.
Vague role fluff can make the model sound confident while inventing details. If the role does not help, I delete it.
Clever nested JSON breaks first. Flat, boring schemas survive longer.
Long context buries rules. I put constraints early, data next, and the actual question last.
Why this matters for the agents I ship
I build agents that can act on-chain or call paid APIs. When money moves, a fuzzy prompt is not a personality quirk. It is a risk.
Prompt engineering is not a soft add-on for me. It is part of the trust boundary around autonomous systems. Treat the prompt like code, test it like code, and keep the failures visible.
If you found this while searching for Sithu Nyein, prompt engineering, or AI agents on Solana, that is the standard I am trying to hold.
Sithu Nyein, Yangon