Hacker News: ericmaciver

New comment by ericmaciver in "Ask HN: Why are Claude models so verbose?"

ericmaciver — Fri, 28 Aug 2026 04:25:38 +0000

I've had to put hard rules into Claude - and I still have to reinforce them - not just CLAUDE.md (make sure not over 40k characters) but hooks that force a read of .md files on startup, etc. Some sessions still bend the rules along the way, but hooks help bring them back into line automatically. I don't worry too much about verbosity - so I haven't tried to curb that. I just ask "give me the short version" when needed. I let the comments happen for future session passes.

As for "things solved by X" - part of my rules includes a list of "check X first" before planning or implementation - do not reinvent what is already solved". Seems to help.

New comment by ericmaciver in "Launch HN: OneCLI (YC S26) – OSS sandboxed agent harness for teams"

ericmaciver — Fri, 21 Aug 2026 22:48:40 +0000

The "policy in one place, enforced across every agent" part is the piece I would have underrated a year ago.

I went looking for that in my own codebase and found six independent secret-redaction denylists, no two of which agreed. Measured against 17 real credential shapes, the list I thought was canonical caught 10. The seven it missed included a GitLab PAT, a Supabase key, a Cloudflare token and a literal password= . The widest list was a fork, not the canonical one, and only the union of all six covered everything. Nobody wrote six on purpose. Each was locally reasonable when it was added and there was no single place to put the rule.

So the question I would ask about the team layer: when a policy changes, is there exactly one artifact every agent reads, and can I diff what an agent was actually allowed to touch at run time against what the policy said? Enforcement I can audit afterward is worth a lot more to me than enforcement I have to trust.

New comment by ericmaciver in "Ask HN: I hate coding agents. Is this skill issue?"

ericmaciver — Tue, 14 Jul 2026 23:37:00 +0000

I used to watch a window code - each line - but that was too much. I ended up just making sure adversarial reviews are performed for every task, a completion report generated to my personal preferences and then I feed multiple tasks through an an orchestrator that keeps the high-level context in play, which aligns work with my objectives before merging it. It knows my preferences, and runs audits itself, along with automated tests. It took a long time to tweak it to a point where I can stay involved in the choices and code while maximizing throughput - but the work put into the ecosystem has (so far) paid off.

New comment by ericmaciver in "Show HN: AI vs. AI – code and reviews only count if they survive an attack"

ericmaciver — Fri, 19 Jun 2026 20:06:59 +0000

The version that boosted improvement for me: make the reviewer a different model than the one that wrote the code, and prompt it to be adversarial: refute rather than green light. A launch-blocker fix that compiled and passed every test still had 3 real bugs - the adversarial cross-vendor pass was the only thing that caught them. Same-model self-review mostly rubber-stamps. That being said, I usually run same-vendor in parallel though, just for instant consensus on the major issues, but I direct fixes based on the adversarial model. The "survive an attack" part is key.