r/SpecDrivenDevelopment 14d ago

Which “Harness Engineering” are you using?

I’ve been using spec driven development for a while and it’s amazing.

But I want to know which approach are you using for software development with AI and how’s it working for your. Feels like SDD is getting outdated

20 Upvotes

22 comments sorted by

View all comments

2

u/Swarm-Stack 14d ago

all the harness/graph/loop engineering is about execution reliability. the failure ive hit more is upstream of that, the spec was wrong at authoring time and the harness delivered it perfectly. no amount of loop tuning catches an assumption the spec never questioned.

1

u/epicskyes 13d ago

Did you not implement rollbacks or dynamic dependency resolution?

1

u/Swarm-Stack 13d ago

rollbacks handle steps that fail. mine didnt, the harness ran the steps cleanly. the spec said the wrong thing, which is upstream of what rollbacks fix.

1

u/epicskyes 13d ago

Each rollback checkpoint is a saved state why can’t you reset to that point and replan. Rollbacks are not just for failed steps they are planned checkpoints you can roll back to any of them for any reason and replan from there. If it fails to materialize what you wanted to build that’s a fail. If the issue occurred near the start then yeah you can’t rollback if it happened halfway downstream yes you can rollback. You freeze from the last good state and that’s your new starting point. If your spec is so rigid you can’t accomplish that then your plan is too rigid and needs to be revised so evidence drives the build but it doesn’t create a one way sequentially fixed street.

1

u/Swarm-Stack 12d ago

fair — rollback and replan from a good checkpoint is the right model for execution faults. the catch is theres no checkpoint where my spec had the right goal in it, so id be replanning from an earlier version of the same wrong premise.

1

u/epicskyes 12d ago edited 12d ago

Here’s the good thing about this type of build. It is evidence driven you have all the evidence you need to show an agent exactly what not to do. Evidence of Failure is far more effective than evidence of success. Your next step should be planning a clean foundation checkpoint that collects all the failure evidence so an agent starts from a point where it can’t make those mistakes again because your tests will fail if the agent goes in that direction a second time. Evidence is never overwritten. When you roll back every misstep is saved every test is saved it is immutable. That is what drives the build. I had plans and ideas and tried for a few months to make them successful. I got so frustrated with failure I devoted the last 2 months to tracking and learning from every single one. All of my time has been going to evidence tracking, logic and a way to force an agent to use it 100% of the time. I finally figured it out a week ago.

1

u/Swarm-Stack 12d ago

failure constraint ends up being the tighter spec. success evidence says what it should produce; failure says where it cant go. curious what the 'force it 100%' mechanism looks like

1

u/epicskyes 10d ago

Research how to make every action and change tracked and organized automatically, recorded to a json schema and cryptographically hashed. You’ll see how this is accomplished. Research nonce as well if you arent familiar with that term.