Hacker News: behaviors

New comment by behaviors in "Text-to-CAD"

behaviors — Sun, 03 May 2026 21:19:35 +0000

I've been using an OpenSCAD container with various local models. Dumping the render.png straight to the model, allowing it to modify the code and try again. Made some interesting things, but the main purpose was to fix things I've already made and have some weird single issue that cascades to a broken model if I touch it. OpenSCAD is the first step, FreeCAD and similar(now starting to see more CAD LLM work) are still a WIP. Since january we've solved 4 solid issues I've left on backburner. I use the docker container version with some Custom wrap/bridge work for the render dumps.

New comment by behaviors in "What is Z-Angle Memory and why is Intel developing it?"

behaviors — Sun, 03 May 2026 18:16:50 +0000

Most of the big hit's in tech had a trendy index swinging moment, Intel has been searching for one for a long time since AMD64 undercut the Itanium. Hype drives a currently multi-billion dollar bubble. It's not always a bad idea to throw our holy noodles at the wall. You might find they hover is the sky and grow meatballs, could be big.

New comment by behaviors in "Specsmaxxing – On overcoming AI psychosis, and why I write specs in YAML"

behaviors — Sun, 03 May 2026 18:12:22 +0000

The exact reason you should start with one first. I support maximum specification. Atomic if you will. Lucky for modern development, you don't have to write it, you just have to proof it. If you can read a spec, it can guide your development, might as well have a system to manage them.

New comment by behaviors in "I Built SpecDD Because AI Kept Forgetting What We Were Building"

behaviors — Sun, 03 May 2026 17:59:52 +0000

It's almost once a week I see a very similar approach, with variables for the developer's workflow.

Sounds just like what I've been using, and published as a template: github.com/s1ugh34d/osc (It has a results corpus of testing done) Specs that are LLM driven development, behavior addressed. All markdown human written, LLM's can write them too. The result is tight spec outcomes from LLM's assisting workflows.

Using massive human software specs was great with human developers, but with "clankers" the problem is context. How to wrap software contract context into a markdown file. Works for me, I can have Claude make a osc, review it, amend it, and build a simple solution that has verifiable outcomes.

This SpecDD is very similar, doesn't really need to book of documentation, just a guide really.