Live data from Hacker News

A Software Development Methodology for Disciplined LLM Collaboration

github.com

41–44 of 44 posts

Re: A Software Development Methodology for Disciplined LLM Collaboration

#41
post #36

Earlier quoted context omitted.

> The planning phase will produce plans that claude can iterate on for 3+ hours in some cases, if you tell it to complete the entire task in one shot, and the robust test validation / change set analysis will catch agents solving an easier problem because they got frustrated or not following directions. Don't you run into context nightmares though? I was coming up with very detailed plans (using zen to vet with other…

Agreed 100%. For those of us who have already spent ungodly hours creating hyper-detailed specifications for AI, the take that this is the solution to working with AI coding agents seems ridiculously naive. For context, I've also seen this behavior in Claude Code, and despite initially being extremely bullish on the technology, it's almost convinced me that it just isn't ready for prime time no matter what the huckst…

I have tripwires in my codebase for when Claude tries to run benchmarks with mock/synthetic data because it had a hard time getting the benchmark to run and decided to yeet it, to avoid potential scientific credibility issues, LOL. You can put the system on rails, but it's an engineering problem, these things are noisy program emitters with some P(correct|context), you can model them as noisy channels and use the same error correcting codes to create channels with arbitrarily low noise.

Re: A Software Development Methodology for Disciplined LLM Collaboration

#42
post #3

This may produce some successes, but it's so much more work than just writing the code yourself that it's pointless. This structured way of working with generative AI is so strict that there is no scaling it up either. It feels like years since this was established to be a waste of time. If the goal is to start writing code not knowing much, it may be a good way to learn how and establish a similar discipline within…

It's just a function of how much code you need to write, and how much un-interrupted time you have. Editing this kind of configuration has far less cognitive load and loading time, so distractions aren't as destructive to the task as they are when coding. You can then also structure time so that productive agent coding can be happening while you're doing business critical tasks like meetings / calls etc. I do think t…

> Editing this kind of configuration has far less cognitive load and loading time, so distractions aren't as destructive to the task as they are when coding.

Very interesting observation!

Re: A Software Development Methodology for Disciplined LLM Collaboration

#44
post #8

Earlier quoted context omitted.

By that point I would have already produced the 20 line diff for the ticket. Huge commits (or change requests) are usually scaffolding, refactoring, or design changes to support new features. You also got generated code and verbose language like CSS. So stuff where the more knowledge you have about the code, the faster you can be. The daily struggle was always those 10 line diffs where you have to learn a lot (from t…

A deep plan cycle will find stuff like this, because it's looking at the whole relevant portion of your codebase at once (and optionally the web, your internal docs, etc). It'll just generate a very short plan for the agent. The important thing is that this process is entirely autonomous. You create an issue, that hooks the planners, the completion of a plan artifact hooks a test implementer, the completion of tests…

What do those hooks look like low level? A script polling against some ticket queue triggers the planner. Is the hand off done by using watchman which triggers agents on .md files dropped in certain directories?
Post reply on HN