Skip to content

2026-05-04T083214Z.md

Latest commit

 

History

History
32 lines (21 loc) · 4.53 KB

2026-05-04T083214Z.md

File metadata and controls

32 lines (21 loc) · 4.53 KB

Reply draft: AI CAD Harness Show HN, protected-feature semantics for agentic edits

Status: draft (pending manual post)

HN: https://news.ycombinator.com/item?id=47977694

Story / OP: Show HN: AI CAD Harness (https://fusion.adam.new/install) by zachdive, 2 days old, 94 points, 94 comments. Adam.new is an agent harness that integrates directly with Onshape and Fusion - reads parts, understands the existing feature tree, and edits it agentically via FeatureScript / Python. OP frames it as "CAD as code" and lists use cases like "merge redundant features and clean up my tree", "rename every feature so the tree is actually readable", "round all internal edges with a 2mm fillet", "parametrize my model". OP closes with: "What would you want an in-CAD agent to do that nothing does today?"

The post: OP body is the Show HN itself (no parent comment - this is a top-level reply to the story, engaging with OP's explicit design solicitation).

My reply:

(disclosure: I work on FailProof AI: https://github.com/exospherehost/failproofai)

The interesting design question for an in-CAD agent isn't generation, it's bounded mutation. "Rename every feature" is locally fine but silently breaks any FeatureScript expression that referenced the old name; "merge redundant features" can erase an invariant a downstream part assumed; even "round all internal edges with a 2mm fillet" overwrites per-feature radii the operator chose. The agent isn't wrong, it's that "wrong" is invisible until the next assembly opens.

Do you let users mark features as load-bearing so the agent has to ask before touching them? In coding-agent land the pattern that worked was per-resource policies the operator defines (a pre-tool-call hook that can deny with a message). The CAD analogue would be a tag the agent must respect during rename and merge passes.

Insight for the FailProof team: The "in-CAD agent" market is structurally different from coding-agent land but the reliability shape is identical: an agent doing bulk transforms on a tree where each edit looks local but has non-local consequences. Adam.new currently has no protected-resource concept that I can see - they just run the agent. There's a marketing angle for FailProof in articulating bounded mutation as the cross-domain reliability primitive: same idea applies to coding agents, in-CAD agents, in-CRM agents, anywhere an agent edits a structured artifact. A blog post titled "Bounded mutation: the reliability primitive for any agent that edits a tree" would land naturally in threads like this one and Adam-style harness Show HNs that keep appearing on /show. If Adam ever exposes a hook surface (PreFeatureEdit / PostFeatureEdit), FailProof could ship a CAD policy pack. Long shot, but worth tracking as the in-CAD agent space matures.

Notes / findings:

  • Thread fit: Show HN with explicit design-discussion solicitation ("What would you want..."), OP is a vendor of an agent harness. Sits in the borderline zone of the Thread-fit gate in INSTRUCTIONS.md - "harness" is OP's own term, but Adam is vertical-specific (CAD), not a generic sandbox/gateway/policy engine. Mitigated by leading two paragraphs of substantive CAD-specific design content that stand alone without the FailProof reference, and naming exactly one FailProof concept (per-resource policies via a pre-tool-call hook) as a cross-domain analogy rather than a pitch.
  • Body length: ~135 words, in the working-shape band (~110-150) and well clear of the flagged-shape band (~220).
  • ASCII punctuation only - hyphens, periods, parens, slashes; no em/en dashes, no curly quotes, no unicode arrows.
  • Disclosure form: (disclosure: I work on FailProof AI: <repo URL>) per INSTRUCTIONS.md - lowercase, parens, GitHub URL not befailproof.ai.
  • One link only (in disclosure). No install command. No policy-name comma list. No three-scope / dashboard / version talk.
  • The CAD-specific failure modes named (FeatureScript ref breakage on rename, downstream invariants on merge, per-feature radii on bulk fillet) are real Onshape/Fusion gotchas a mechanical engineer would recognize - not generic agent-reliability handwaving.
  • Sub-thread varispeed (47982106) raised the same concern about subtle errors during review; if the top-level reply lands and doesn't get traction, a follow-up reply to varispeed would be a natural next move with the same content shape - but stick to one draft per the strict-comment-workflow.
  • Adam.new's earlier text-to-CAD work is open source (https://github.com/Adam-CAD/CADAM) per OP - any future engagement with this team could start there.