A No-Implementation Kickoff and a 12-Question Interview
Notes on a kickoff prompt that banned writing implementation code and demanded an interview first, at the start of designing the trading bot.
This is where the trading bot starts. It places orders through a brokerage Open API: the rule engine generates the signals and the LLM only reviews them. The system that keeps coming back later in the series is settled here.
Sunday night, I wrote the first prompt for the trading bot project. This time the goal was to receive not a single line of code.
What I set out to do
It’s a trading bot built on a brokerage’s Open API. Finish it in paper trading, then switch to live, and run it unattended as a launchd resident daemon on a single Mac mini; that’s the end state. I set the structure as a hybrid. Only the rule engine generates trade signals, and the LLM merely reviews each signal as APPROVE/REJECT/REDUCE. Real money rides on this system, so I wanted to avoid the usual flow where one “build it” and code comes pouring out.
How I asked
The first line of the kickoff prompt was a prohibition.
This is the design phase. Do not write a single line of implementation code. The only deliverables are design documents under docs/.
I pinned down a few more requirements. First, prove through the design that the principle “the LLM cannot create orders” is enforced at the code-path level, not the prompt level. Second, the failure-modes document is the heart of this design; since money is at stake, spend more pages on failure paths than on the happy path. Third, I’m a backend developer with nine years in, so keep explanations concise, and when code is eventually written, make it production-grade. I also locked the process into three phases. Phase 1: interview. Phase 2: preliminary research on the brokerage API. Phase 3: review seven design documents and ADRs one at a time.
Where it broke
In the phase-1 interview, Claude threw 12 questions at me all at once. It was a diligent questionnaire, with A/B/C options per item, trade-off explanations, and a starred recommendation. The problem was me. Nine years of backend, sure, but investing isn’t my specialty, and I didn’t understand about half the questions themselves. I sat on it for 15 minutes and then sent a reply.
- Go with your recommendation. 4. I’m not an expert on this either, so your recommendation; the direction you’re recommending is right, yes? … That was too many questions at once.
The back half of the reply was a loop of “I don’t know what this means, your recommendation” and “explain again, your recommendation.” I answered 8 of the 12 with “your recommendation,” and wrote in my complaint about the number of questions as-is. I’d ordered an interview so I could make the design decisions myself, and then handed two-thirds of the decisions right back.
How I fixed it
In the end, the interview format saved me. With options, trade-offs, and a recommendation attached to every item, decisions keep moving even when I answer an unfamiliar area with the single word “recommendation.” I decided only the items I knew: 30 million won of paper-trading capital, domestic market only. A structure where I delegate the rest formed naturally. Concepts I didn’t understand, I asked to have explained again. When I asked what a hysteresis band was, it re-explained with the analogy of “the magnet that clicks a door open or shut,” and only then did I understand what I was deciding. After the interview we moved on to phase 2, preliminary research on the brokerage API. Tonight’s output contains not one line of code.
Lessons
- Putting “do not write a single line of implementation code” in the first line locked the day’s output to design documents. An explicit prohibition worked better than a vague request.
- Thanks to the interview format with options, trade-offs, and recommendations, I could delegate non-expert areas via “recommendation” and decide only the items I knew myself.
- That said, dumping 12 questions in one batch was too much. From the next interview on, I should control the question count in the prompt too.
- If money is on the line, better to state up front: spend more pages on the failure paths.
- For core principles, demand that the design prove they’re enforced by structure, not promised by a pledge to “follow them.”