dnh44

Yeah that makes sense. People will be often more polite when they realise there is a real human on the other side.

But I was referring more to the initial use of strong words coming from frustration.

Just because you deal with it well doesn’t mean you should have to deal with it in the first place, especially when it comes to volunteer work.

I’m developing three codebases right now where all of the code is written by AI (Swift, Python, Rust) and the Rust codebase requires the least pruning and has the fewest wtf moments.

I feel really bad for the sense of entitlement a lot of open source devs have to deal with. Imagine building something for free as a hobby then having to deal a mob of angry people who have never paid you whenever you do something they don’t like. Surely your first thought would be to tell them to foxtrot oscar somewhere else.

To be honest Copilot really stinks and is really far from the sharp edge of what is possible these days.

I regularly get codex to do multi hour tasks with a single prompts I don't think thats a big deal anymore. But you don't want a single agent doing all the work. The root agent needs to delegate the work to sub agents. For example, a sub agent for context gathering, then one for planning, then one (or more) for implementation, then another for review. This way the root agent doesn't use up its context window and it just manages from a bird's eye view. I do have the $200 plan though.

thanks for the tip will check it out!

you don't think kids should play sports? that seems like an unusual view and am kind of curious why you would think that.

If you make iOS apps you can also set up an Xcode Cloud pipeline so the result gets pushed to your phone via TestFlight.

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.

>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.

The process no longer feels like a slot machine.

>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.

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 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.

Thanks for the reminder! It’s very likely I read that post as a teenager.

I always liked Stardock; if had to use Windows I'd definitely just get all their UI mods out of the nostalgia factor.

Yeah it is a bit isn't it

I loved OS/2 but I also remember the dreaded single input queue... but it didn't stop me using it until about 2000 when I realised it was time to move on.

>I thought these tools are so great, so awesome, that even without much experience they will help you?

I never made that claim, I don't think it's generally true, but I do think it can be true for some people.

Regarding the study, I pointed out why I thought it was limited in its scope. If someone did a study on the potential productivity gains of using emacs and they based the study on people who had only used it for a week it wouldn't be a particularly useful study. A Piano is not a useful tool for making music for someone who has only used it for a week either.

I do have a customer with no prior programming experience that has created custom software for his own small manufacturing business automating tedious tasks. I think that's pretty amazing and so does he.

I think that in that study all but one of the devs had hardly any experience with using AI tools.

I find that X and Discord are more useful than HN for trying to keep up to date. Which is a shame I think but it is what it is.

One side effect of writing most of my code with an llm for the past six months is that I'm so much better at reading code I didn't write. It's also forced me to split my code up in smaller more modular files to make it easier for me to understand, which has the happy side effect of having a better designed system. It's counter intuitive but I think I've become a better programmer for it because it's forced me to level up my weaknesses.

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'm of the same opinion as the op and I'm programming in Rust(api) and Swift(client) right now.

I entered a vibe coded game hackathon a few months back and in a little over a week I was at 25k lines of code across both the client and server. It all worked (multiplayer) even though the game sucked.

I use a program called RepoPrompt to do it. The dev has a video here:

https://www.youtube.com/watch?v=JzVnXzmZweg&t

You're not pushing them hard enough if you're not seeing a vast difference between 4o and Opus. Or possibly they're equivalent in the field you're working in but I suspect it's the former.

Last summer I came back to software after about 12 years away and I pretty much had an identical experience to you with using AI as a helper to come back. I've now spent the last 6 months coding as much as I can in between consulting gigs. I'm not sure if I would have been able to get caught up so quickly without AI.

I haven't had this much fun programming since I was at university hacking away on sun workstations, but admittedly I only write about 10% of the code myself these days.

I'm currently getting Claude Code to pair program with GPT-5 and they delegate the file edits to Gemini Flash. It's pretty cool.

Codex CLI has got better at this although I don't think it's better than Claude Code yet

If you’re using an LLM near the limits of what it can do then a small improvement in performance is noticeable.