Do you see any value in adding standard development and architecture design docs into your flow? For example … consuming a pre-existing ADR, or generating one at the end of your process?
Your architecture and tasks MD are optimized for vibe coding, but may not help six months down the road when a developer may scrub in to maintain a component or port it to some other environment.
Just thinking about how to lubricate the handoff back and forth between human and machine.
Hey Joe, I am not sure because I haven't applied this approach to this type of situation yet. I do think the artifacts remain human readable, and there is always a readme.md that explains what the project does. I think a human developer could navigate the code fairly easily.
I think the final product's quality and tests remain essential and for "real" projects I would still conduct a fairly thorough review before "shipping".
Other artifacts might be useful too? Time will tell. Curious to hear what you learn if you conduct any experiments along those lines. My next interest is to see how much I can do from just a diagram defined with a DSL..
I'm going to lean into your approach. I've been on the same boat for a few months playing with Vibe coding (quasi Vibe coding) but for some reason I feel compelled to take over and code or move on to the next random project I want to play with without seeing the whole thing thru.
Do you see any value in adding standard development and architecture design docs into your flow? For example … consuming a pre-existing ADR, or generating one at the end of your process?
Your architecture and tasks MD are optimized for vibe coding, but may not help six months down the road when a developer may scrub in to maintain a component or port it to some other environment.
Just thinking about how to lubricate the handoff back and forth between human and machine.
Hey Joe, I am not sure because I haven't applied this approach to this type of situation yet. I do think the artifacts remain human readable, and there is always a readme.md that explains what the project does. I think a human developer could navigate the code fairly easily.
I think the final product's quality and tests remain essential and for "real" projects I would still conduct a fairly thorough review before "shipping".
Other artifacts might be useful too? Time will tell. Curious to hear what you learn if you conduct any experiments along those lines. My next interest is to see how much I can do from just a diagram defined with a DSL..
I'm going to lean into your approach. I've been on the same boat for a few months playing with Vibe coding (quasi Vibe coding) but for some reason I feel compelled to take over and code or move on to the next random project I want to play with without seeing the whole thing thru.
Yeah good point. I’ve done the same in the past. This spec thing makes it a lot easier to get across the finish line vs getting stuck at 80% complete.