Hacker News Reader

Comment by qazxcvbnmlp | Hacker News Reader

My mental model is that ai coding tools are machines that can take a set of constraints and turn them into a piece of code. The better you get at having it give its self those constraints accurately, the higher level task you can focus on.

Eg compiler errors, unit tests, mcp, etc.

Ive heard of these; but havent tried them yet.

https://github.com/hmans/beans

https://github.com/steveyegge/gastown

Right now i spent a lot of “back pressure” on fitting the scope of the task into something that will fit in one context window (ie the useful computation, not the raw token count). I suspect we will see a large breakthrough when someone finally figures out a good system for having the llm do this.

View on HN

> Right now i spent a lot of “back pressure” on fitting the scope of the task into something that will fit in one context window (ie the useful computation, not the raw token count). I suspect we will see a large breakthrough when someone finally figures out a good system for having the llm do this.

I've found https://github.com/obra/superpowers very helpful for breaking the work up into logical chunks a subagent can handle.

How would you compare it to Claude Code in planning mode?

I've only used Claude's planning mode when I just started using Claude Code, so it may be me using it wrong at the time, but the superpowers are way more helpful for picking up on you wanting to build/modify something and helping you brainstorm interactively to a solid spec, suggesting multiple options when applicable. This results in a design and implementation doc and then it can coordinate subagents to implement the different features, followed by spec review and code review. Really impressed with it, I use it for anything non-trivial.

I asked because I started using GSD which I liked at first, but have since dropped. I started using planning instead and find it probably does a better job and is waaay faster. After a while of using GSD I started to realize the control I initially felt over the model with all these markdown documents (current state, phases, phases belonging to larger milestones) etc. were an illusion.

Still basically relies on feeding context through natural language instructions which can be ignored or poorly followed?

The answer is not more natural language guardrails, it is in (progressive) formal specification of workflows and acceptance criteria. The task cannot be marked as complete if it is only accessible through an API that rejects changes lacking proof that acceptance criteria were met.

Some specification exists as formal constraints. Ie: c code will or will not compile.

However some specification only exists in natural language. IE: make this page optimized for a smartphone. The task of turning that vague direction into formal requirements is work in and of itself. The more you can have the llm help with that — the more time it will save you.

Reply on news.ycombinator.com