I implemented some corrections on report :
here the SKILL file : SKILL.md
@lud , good questions. I think the easiest way for me to answer is with a high-level overview.
First, I like TDD, DDD, and SDD, and try to incorporate them into most of my projects.
I think building with AI is a different skill set than traditional software development. As others have noted in this forum, AI has the tendency (as of now) to try to force non-idiomatic patterns on Elixir code, so I maintain a healthy skepticism with AI-generated code.
Eventually, I think there’s a significant chance the majority of code may be AI-generated, so I want to be prepared for this, but I don’t think it’s going to happen as fast as some of the big proponents would have you believe. So I’m kind of in this intermediate state where I try to push AI as much as possible with a “trust but verify” approach.
I’m also working on my own harnesses for spec-driven development and multi-agent coordination and task management. My thought is this exercise is a good way to learn about what the symbiosis between AI and developer could look like, and maybe will be a better way to produce quality code with a very specific toolset.
Would love to get your review of packages across the Jido ecosystem, starting with jido_action, jido_signal and jido - I’ll DM you
Well keep me posted!
I’m evaluating Claude Code in deptht for my company right now so I’m writing a feature with mostly long, documented prompts. Well that was the plan but I have to intervene all the time. The code is sometimes ok, sometimes crap.
Consistency is very important in development, but AI is everything but consistent, this is what makes it so unreliable to my eyes. You will get good results with minor problems, which will build your trust and slightly lower your standards at the same time, which is fine since you are delegating to a junior. But it’s a trap.
The best advice I could give you is to get as much hands-on experience using these tools as you possibly can. I think this is the best way to figure out what works for you and what doesn’t.
A few suggestions to look into:
/status command to monitor your usage metrics.
I’ve been a big beads user since last year – i rode along through the iterations as it made the changes through .beads/issues.jsonl → sqlite → daemons → dolt, etc. it’s been rough at times, but when it worked it was beautiful. recently, i’ve had a lot of problems with the direction it’s gone, and the complexity that’s been introduced (and the occasional brokenness).
this pushed me to build a stripped down, focused, stable tool called beadwork – it does the basics, and it does them without all the unnecessary complications of a database… it currently boasts 87% test coverage.
beadwork manages all of the tickets as individual json files on an orphan branch, so it:
as a heavy user of this style of workflow, i’ve been iterating on the tool to streamline it’s interactions with the agent. for example, by adding clean/dirty/branch stats to the bw ready command’s output, i was able to cut the number of tool calls that claude or gemini will make when deciding what to do next. bw prime includes information about in-process and ready tickets, saving more tool calls.
lastly, there’s a lovely import and export command that will happily eat beads’ .jsonl files, so that you can make the switch without losing any of your ticket history.
if you find it useful, let me know! 
