2 days ago
- The author describes a pattern where a harness decides when a coding task is done, continuing iterations if not, creating a loop outside the traditional agent loop.
- There are two loops: the inner agent loop (model calls tools, reads/edits files, runs tests) and the outer harness loop (orchestrating tasks, injecting messages, or starting new sessions).
- The author has not had success with this approach for code they deeply care about due to a desire for control and understanding of the code they ship.
- Current LLMs produce code that is too defensive, complex, and locally reasoned, adding fallbacks instead of making bad states impossible, and loops amplify these issues.
- The loop pattern works well for porting code, performance experiments, security scanning, and research—tasks that produce short-lived artifacts or mechanical transformations.
- The author likens the shift to moving from software as a deterministic machine to software as an organism, where understanding is harder and machine participation is assumed.
- Pressure from attackers (looping for security issues) and competitive teams (building faster via loops) makes opting out of this future difficult.
- Dependency on machines creates cognitive risks: codebases that require machine participation for maintenance, and loss of human ability to understand code without LLMs.
- Better tooling is needed to retain human understanding, not just more loops; the question is how to keep judgment, good engineering, and human supervision in a loop-dominated future.
- The author is uneasy but acknowledges the inevitability of loops, emphasizing the need to architect code and harnesses to maintain sanity and responsibility.