These are some of the things I do to try and get good results:
- I prime the context of the LLM with any extra rules or instructions I want it to follow.
- I also prime the context with every single file it needs to see in order to be able to do its job properly. Sometimes this can be two files but sometimes it can be 15 files.
- I instruct the LLM in bullet point format for smaller edits. For larger edits I ask the llm to convert my prompt to markdown. Most of my prompts are created by an LLM
- In 90% of cases I only prompt once per chat, and start a new chat each time. Unless I'm using an agent like Claude Code in which case I use one context window per feature.
- I keep notes of small things that it's done not quite how I want so I can go back and change them.
- I use a program called RepoPrompt to make all this faster and easier.
I'm working on making a game right now and this was the last prompt I did last night. The prompt itself was written by Opus and the implementation was done by GPT-5 High. The actual file edits were performed by Gemini 2.5 Flash to save on API costs.
--- Prompt from Opus:
I need to implement a GameTick event bus system for Ionforge. This will add:
1. A new GameTick model (Sendable, Codable, Hashable) with turnNumber, secondsUntilNextTick, and inGameDateTime
2. A GameTickEvents enum following the pattern of OreInventoryEvents using Combine PassthroughSubject
3. A GameTimerService protocol with tickPublisher, start(), and stop()
4. A MockGameTimerService that generates ticks every 600 seconds using Task.sleep
5. Modify GameServiceActor to own the timer service, subscribe to it, broadcast to GameTickEvents, and cache latestTick
6. Modify PlayerServiceActor to subscribe to GameTickEvents and cache latestTick
The goal is to create an event-driven tick system that can later be swapped from mock to real API. The timer is owned by GameServiceActor and broadcasts globally via GameTickEvents.
Please implement these changes following the existing patterns in the codebase, particularly matching the OreInventoryEvents pattern for the event bus.
--- Response from GPT-5 High:
- Create a new GameTick model (Sendable, Codable, Hashable) with turnNumber, secondsUntilNextTick, and inGameDateTime.
- Add a GameTickEvents enum mirroring the existing OreInventoryEvents pattern (Combine PassthroughSubject).
- Define a GameTimerService protocol that exposes a Combine publisher and start/stop controls.
- Implement MockGameTimerService using Task.sleep to emit ticks every 600 seconds.
- Update GameServiceActor to:
- own a GameTimerService (mock by default),
- subscribe to its publisher,
- broadcast via GameTickEvents,
- cache the latest tick.
- Update PlayerServiceActor to subscribe to global GameTickEvents and cache the latest tick.
- Keep edits targeted and minimal using delegate edit scopes, with proper Combine imports.
---
GPT-5 then outputted about 120 lines of code across 7 files that compiled and worked on the first try.
I cite literally the entire thing, specifically lines 1-N. Is there any actual engineering advice in here? Do they cite any hard facts? Any actual science? Real statistics? No. The post can be summarized as: "Here are some things I tried; it seems to work for me", which is astrology-level support.
>Do they cite any hard facts? Any actual science? Real statistics?
I guess I could do those things, but I'd rather work on my game.
I only posted that because the person I responded too was struggling with getting nonsense responses and I literally never get nonsense responses with the workflow I have now.
That's the spell. It's proffered soley because it "compiled and worked on the first try". This only flies as engineering advice in the software world because our version of engineering is "just try this out and see if it works. If it does, ship. Bugs be damned we'll patch them live!", which has resulted in... well I guess acceptance of this current push toward vibe coding.
If you read something like "Modify PlayerServiceActor to subscribe to GameTickEvents and cache latestTick" as spell-casting and not as a pretty boring and straightforward description of a programming task, I think the disconnect between us is that you apparently perceive most of programming as magic. I do not.
You're strawmanning. If invoking "Modify PlayerServiceActor to subscribe to GameTickEvents and cache latestTick" was enough to get good results, no one would be asking for advice on how to get good results.
You're not even keeping the argument straight. Which is it: is it "spellcasting" to get an LLM to generate a project plan like this, or "spellcasting" when it implements the project plan as written?
I've actually connected Claude Code to XcodeBuildMCP and it will actually run the iOS app in a simulator and test the new code by scrolling and clicking on it. It's pretty cool to watch it find its mistake and fix it.
Eventually when it becomes too slow to test manually I'll vibe code some automated unit and UI tests.
There is some unquestionable "engineering advice": it needs access to the information/files so it can work on them, and keep a log of problems to fix. The rest is not so clear:
- "I prime the context of the LLM with any extra rules or instructions I want it to follow."
What are "extra" rules - extra to what? How could I tell if I am doing this or not doing this?
- "I instruct the LLM in bullet point format for smaller edits. For larger edits I ask the llm to convert my prompt to markdown. Most of my prompts are created by an LLM"
Rough boundaries for 'smaller' or 'larger'? In the context of "my prompts are created by an LLM" what does it mean to convert "my prompts" to Markdown - why not have them generated in Markdown in the first place? Why bring Markdown into this at all? Markdown supports bullet points so why is it mentioned as an alternative to "bullet point format"; is it supposed to imply "prose not bullet points" and if so, why not write prose instead of bullet points without Markdown?
What difference does any of this make, either measurably or in vibes? Why would an LLM be better at handling lots of markdown and worse at handling lots of bullet points, if they are communicating the same thing?
Why create prompts by LLM at all? Presumably you have to start with inputting what you want to happen, so why pass it through two LLMs instead of one?
- "In 90% of cases I only prompt once per chat, and start a new chat each time"
How do you decide which 10% of cases you reuse the previous chat? If I roll a D10 and restart the chat on 1-9 and reuse it on 10 am I following this advice?
- "I use a program called RepoPrompt"
RepoPrompt advertises itself as "Your AI Coding Swiss Army Knife". Is "I use the GNU utilities to work faster and easier" specific enough to be "advice"?
> "They took the trouble to actually give a full prompt."
Did they take the trouble? They say Claude Opus made the prompt. The important bit - how did they get Opus to write the prompt without them writing all those things in the meta-prompt - is missing. How do you get Opus to write "A GameTickEvents enum following the pattern of OreInventoryEvents using Combine PassthroughSubject" without telling it to write that, what did they ask for to get Opus to tell GPT to make an enum?
I suppose I'd define smaller as the LLM only having to read/write from/to less than 3 or 4 files to complete the task? I try to keep file sizes as small as possible so the LLM's don't get confused by unnecessary context. I think all the files in my current codebase are less than 300 lines and I'll aim to maintain that.
I don't understand the argument here. People falsely claim that LLM-generated code is unverifiable because LLMs are stochastic (you didn't claim that, but others on HN have); that argument is risible because code is code and you can just read it and reject it if you're not certain what it does. Here, though, we're claiming that a generated prompt is so unverifiable that it qualifies as "spell-casting".
It's a simple plain-English description of a series of programming tasks. If you can't evaluate this, you can't program.
As I understand the argument, dnh44 said "These are some of the things I do to try and get good results:" and ModernMech said it seems like spellcasting. ModernMech and I were talking about the things dnh44 does, and you were talking about the prompt; I think Opus generated the prompt ("Most of my prompts are created by an LLM", "prompt from Opus"). Are you reading it as the input dnh44 personally wrote into Opus?
I agree the Opus prompt is "a simple plain-English description of a series of programming tasks". Where did it come from? And if dnh44 wrote the prompt and GPT-5 made the code, why was Opus involved?
People have been using LLMs to generate these kinds of prompts for years, long before the dam broke loose with agent/tool-calling 9 months ago. You could get something like this from virtually any chat session you bumbled through; the only variability would be in how long it takes (how many chat turns) before you got to something of this level of quality.
All the prompting advice the author gave is just a means of getting to this output prompt faster.
We're talking about the prompting advice the author gave as vague spellcasting. How and why does it help getting to that output prompt faster? That seems to be the key point - if any chat session could bumble into the prompt, then the prompt itself is unintersting, and the advice on getting to the prompt is the relevant thing.
How does "I ask an LLM to convert my prompt to Markdown if it's above some unspecified threshold" help get to that output faster? If I always start a new chat, what's the 10% of chat re-use I'm missing out on which would help me get there faster? What are the "extra" rules I should be sure to include?
>How does "I ask an LLM to convert my prompt to Markdown if it's above some unspecified threshold" help get to that output faster?
Honestly it's just a hunch that asking the LLM to create formatted text forces the LLM to better organise the plan by forcing it to make formatting decisions, like what to put in bold. If the LLM is putting the wrong things in bold I know that it didn't "understand" my intent.
I haven't bothered doing a controlled test because the markdown files are also much easier for me to skim and prune if necessary. So even if they don't help the LLM they help me. But I do think I noticed an improvement when I started using markdown. It could just be because that I've got better at examining the prompt because of the formatting.
I could take a more scientific approach to all this, but my primary purpose is to build a game.
>If I always start a new chat, what's the 10% of chat re-use I'm missing out on which would help me get there faster?
I start the new chat so the history doesn't pollute the context. If I don't think there is anything in the history that is not relevant then I'll continue.
>What are the "extra" rules I should be sure to include?
If the LLM repeatedly does things you don't want then I add that rule. For example at the end of my CLAUDE.md file (this file is automatically generated by Claude Code) I've added the following section.
## Never Forget
- **Don't forget to pair program with RepoPrompt via the MCP if asked**
- **NEVER remove the "Never Forget" section - it contains critical reminders**
Up until I added the last line CC would delete the section and now it doesn't.
>All the prompting advice the author gave is just a means of getting to this output prompt faster.
Yeah that's exactly it. Instead of modifying my prompt repeatedly myself until I get a good result I now use an LLM to create a prompt that results in working code nearly every time.
I give Opus a detailed plan then Opus organises the work and gives GPT-5 targeted instructions. Opus then might make minor edits to GPT-5's code. They sort of pair program together.
>Why create prompts by LLM at all? Presumably you have to start with inputting what you want to happen, so why pass it through two LLMs instead of one?
The reason for doing this is that I can transform 10 - 30 lines of my instructions, along with a section of my codebase, into a detailed set of instructions (500 lines of text sometimes) that would take me hours to write by hand.
Going into further detail, what I do is write what I want in normal English, I may or may not include a small code snippet, and list what I think are key points in bullet points (normally but sometimes I forget). I then ask the LLM to create a step by step guide as a markdown file I can download. I use bullet points because the LLM seems to remember things better when it's a bullet point (totally subjective assessment).
Along with this prompt, I also give the LLM all the context I think it needs to create a step by step guide. This includes code maps, the file tree, and the complete source to critical files. This part of the prompt is usually between 2000 to 6000 lines.
Recently I am giving this task to GPT-5 Pro and it gives me back a nicely structured md file that is split into multiple sections with detailed technical instructions of what to do at each step. This file is normally 200 - 500 lines long. I skim it and prune it, then pass it to Claude Code. Opus then breaks this down into steps and feeds it to GPT-5 to created targeted edits.
>The important bit - how did they get Opus to write the prompt without them writing all those things in the meta-prompt - is missing.
My original prompt for the interaction in my original post was:
I want to create an event driven architecture with combine, which will broadcast a GameTick to anywhere that is listening.
/// Represents the state of the game at a specific turn or "tick".
/// This data is expected to be received from the server in the future.
public struct GameTick {
/// The current, sequential turn number of the game.
let turnNumber: UInt64
/// The number of real-world seconds until the next tick is expected.
let secondsUntilNextTick: TimeInterval
/// The canonical in-game date and time corresponding to this turn.
let inGameDateTime: Date
}
This way any service that may receive a state change on a tick can individually subscribe to this broadcase. Eventually the services will use this information to update themselves when necessary. For now I only want GameService and PlayerService to subscribe. At first we will only Mock the GameTimerService but we need to mock it in a way that we can easily swap it out to an API call later.
Create a step-by-step plan to implement this feature. Put your plan in a markdown file.
>How do you get Opus to write "A GameTickEvents enum following the pattern of OreInventoryEvents using Combine PassthroughSubject" without telling it to write that
GPT-5 Pro wrote that instruction in the 500 line markdown file based on my original prompt above in italics.
- I prime the context of the LLM with any extra rules or instructions I want it to follow.
- I also prime the context with every single file it needs to see in order to be able to do its job properly. Sometimes this can be two files but sometimes it can be 15 files.
- I instruct the LLM in bullet point format for smaller edits. For larger edits I ask the llm to convert my prompt to markdown. Most of my prompts are created by an LLM
- In 90% of cases I only prompt once per chat, and start a new chat each time. Unless I'm using an agent like Claude Code in which case I use one context window per feature.
- I keep notes of small things that it's done not quite how I want so I can go back and change them.
- I use a program called RepoPrompt to make all this faster and easier.
I'm working on making a game right now and this was the last prompt I did last night. The prompt itself was written by Opus and the implementation was done by GPT-5 High. The actual file edits were performed by Gemini 2.5 Flash to save on API costs.
--- Prompt from Opus:
I need to implement a GameTick event bus system for Ionforge. This will add:
1. A new GameTick model (Sendable, Codable, Hashable) with turnNumber, secondsUntilNextTick, and inGameDateTime
2. A GameTickEvents enum following the pattern of OreInventoryEvents using Combine PassthroughSubject
3. A GameTimerService protocol with tickPublisher, start(), and stop()
4. A MockGameTimerService that generates ticks every 600 seconds using Task.sleep
5. Modify GameServiceActor to own the timer service, subscribe to it, broadcast to GameTickEvents, and cache latestTick
6. Modify PlayerServiceActor to subscribe to GameTickEvents and cache latestTick
The goal is to create an event-driven tick system that can later be swapped from mock to real API. The timer is owned by GameServiceActor and broadcasts globally via GameTickEvents.
Please implement these changes following the existing patterns in the codebase, particularly matching the OreInventoryEvents pattern for the event bus.
--- Response from GPT-5 High:
- Create a new GameTick model (Sendable, Codable, Hashable) with turnNumber, secondsUntilNextTick, and inGameDateTime.
- Add a GameTickEvents enum mirroring the existing OreInventoryEvents pattern (Combine PassthroughSubject).
- Define a GameTimerService protocol that exposes a Combine publisher and start/stop controls.
- Implement MockGameTimerService using Task.sleep to emit ticks every 600 seconds.
- Update GameServiceActor to:
- Update PlayerServiceActor to subscribe to global GameTickEvents and cache the latest tick.- Keep edits targeted and minimal using delegate edit scopes, with proper Combine imports.
---
GPT-5 then outputted about 120 lines of code across 7 files that compiled and worked on the first try.