Hacker News Reader

Comment by giancarlostoro | Hacker News Reader

> Spec-driven development is becoming the primary driver of code generation.

This sounds like my current "phase" of AI coding. I have had so many project ideas for years that I can just spec out, everything I've thought about, all the little ideas and details, things I only had time to think about, never implement. I then feed it to Claude, and watch it meet my every specification, I can then test it, note any bugs, recompile and re-test. I can review the code, as you would a Junior you're mentoring, and have it rewrite it in a specific pattern.

Funnily enough, I love Beads, but did not like that it uses git hooks for the DB, and I can't tie tickets back to ticketing systems, so I've been building my own alternative, mine just syncs to and from github issues. I think this is probably overkill for whats been a solved thing: ticketing systems.

View on HN

I am going lower level - every individual work item is a "task.md" file, starts initially as a user ask, then add planning, and then the agent checks gates "[ ]" on each subtask as it works through it. In the end the task files remain part of the project, documenting work done. I also keep an up to date mind map for the whole project to speed up start time.

And I use git hooks on the tool event to print the current open gate (subtask) from task.md so the agent never deviates from the plan, this is important if you use yolo mode. It might be an original technique I never heard anyone using it. A stickie note in the tool response, printed by a hook, that highlights the current task and where is the current task.md located. I have seen stretches of 10 or 15 minutes of good work done this way with no user intervention. Like a "Markdown Turing Machine".

If you are using claude, in your project's `.claude/settings.json` you can add something like:

```

  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "mix format ${file} 2>/dev/null || true"
          }
        ]
      }
    ],
    "TaskCompleted": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "prompt",
            "prompt": "reminder: run mix test if implementation is complete"
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "prompt",
            "prompt": "Check if all tasks are complete. If not, respond with {\"ok\": false, \"reason\": \"what remains to be done\"}."
          }
        ]
      }
    ]
  },

```

Just update it to iterate over your file. It should be a little easier to manage than git hooks and can hammer in testing.

That's hilarious, I called it gates too for my reimplementation of Beads. Still working on it a bit, but this is the one I built out a month back, got it into git a week ago.

For me a gate is: a dependency that must pass before a task is closed. It could be human verification, unit testing, or even "can I curl this?" "can I build this?" and gates can be re-used, but every task MUST have one gate.

My issue with git hooks integration at that level is and I know this sounds crazy, but not everyone is using git. I run into legacy projects, or maybe its still greenfield as heck, and all you have is a POC zip file your manager emailed you for whatever awful reason. I like my tooling to be agnostic to models and external tooling so it can easily integrate everywhere.

Yours sounds pretty awesome for what its worth, just not for me, wish you the best of luck.

https://github.com/Giancarlos/GuardRails

This is built in to Claude Code, when you're in plan mode it makes a task MD file, even giving it a random name and storing it in your .claude folder.

I'm confused how this is any different to the pretty standard agentic coding workflow?

that's similar to the workflow i built, inspired by Recursive Language Models: https://github.com/doubleuuser/rlm-workflow

Me too. I've been using spec-kitty [0], a fork of Spec Kit. Quite amazing how a short interview on an idea can produce full documents of requirements, specs, tasks, etc. After a few AI projects, this is my first time using spec driven development, and it is definitely an improvement.

[0]: https://github.com/Priivacy-ai/spec-kitty

Nice, I'll check yours out after work, looks pretty polished.

I’m testing this as well, but I’ve no idea people are getting good results out of Claude. What a waste of money… it’s incredible. It will get stuck on everything: basic string substitution, trying to install Python dependencies in a Node project, finding usages of something it’s trying to edit, and on and on.

Task management is fundamentally straightforward and yet workflow specific enough that I recommend everyone just spend a few hours building their own tools at this point.

Beads is a nightmare.

I started off with the original beads and it was definitely a nightmare. However I would recommend using https://github.com/Dicklesworthstone/beads_rust - it's a much simpler implementation of the same concept, without all the random extra stuff thrown on to support Gas Town.

`br` is still massively larger than necessary for the feature set.

I didn't mention above but I made https://github.com/wedow/ticket as my beads replacement back at the end of December.

I have zero reach compared to Jeff there so I'm considering `ticket` to be a smash hit at this point ;)

Reply on news.ycombinator.com