Automating Myself Out of Development - part2
SubscribeSign in
Automating Myself Out of Development - part2<br>I overshot and got into self-doubt spiral
Nune Isabekyan<br>Jun 09, 2026
Share
I had a hard time finishing this article to be honest. I couldn’t understand myself if what I was building is the right way or not. And so I sat on it for too long and forgot a lot of implementation details. So this one is going to be a bit messier, but there’s some “kern” in it, so if you will, bear with me, and let’s figure things out together.<br>What helped me get out of the state of dread and actually finish it were two things<br>a) the conversation with Ia - she said something along the lines “we suddenly stopped being part of development with AI, but then we realized that we can build systems around AI to create code”. and<br>b) Adrian’s book “Why We Still Suck at Resilience” - and I’ll tell you how in the end.<br>But let’s get to it in order. In my last article I walked with you through moving my Claude Code development away from my local machine and into an ec2 instance, writing a skill that can brainstorm/plan/implement the way I want it to, putting a few cron daemons in front of it so features could get specced, planned and implemented overnight against GitHub issues. The state machine lived in issue labels. I touched it five times per feature - all of them either editing a file or flipping a label.<br>Learning from change
What I actually forgot to tell you, because the article was getting too long as is, is that I also wanted to make it “self-learning” (don’t get agitated, I know it’s not really LEARNING, and I will write about that soon as well) from differences between the spec it created and the version of the spec I really wanted. So Claude code would create the initial spec, I’d review and correct it, and somewhere in one of those daemons I asked it to “compare” the two versions and suggest what kind of information is worth “storing in memory” for the next time.<br>Modifying a file and then asking LLM to diff-and-learn-from-it feels SO CLUNKY I can’t believe I did that. One comment from Lina snapped me out of it - she mentioned communicating through comments, assigning the task back and waiting for the output - and of course that feels way easier, than modifying the file created and then hoping it’ll get the diff right. The thing is, I forced it to try to reconstruct my intent from a diff, instead of telling it my intent .<br>So I changed that part - which also simplified my daemons to be honest. I so love when something I do for an unrelated reason, affects another part - this means there was a coupling between those two things in the first place and I just added the right component that would support both.<br>Here’s how it went: I first created the handler for when I need changes in the spec. If the issue was in the state “spec:needs-review” and I added the “claude:work” and commented something about what I didn’t like in the spec, the daemon would handle it with “revise-spec” handler, which would eventually develop its own complexity. Then I realized that sometimes I had questions, sometimes I had answers...so I added a categorizer of comments. Here’s what it does now:<br>classify what I wrote in the comment as question or directive
answers the question OR finds the place in the spec that this directive is addressing (e.g. there were OPEN QUESTIONS in the original spec that claude created and I answer with Q1: do X instead of Y) and edit the spec if needed
evaluate if it’s worth saving “that” (the question it had, my answer, the consequences of it) into the memory
log log log everything it’s doing
Learning, redone
So now it suggests learning based on my comments, not the diff between spec-as-AI-imagined it and spec-as-I-corrected-it.<br>No auto-learning though. Suggest in comments and let me react to it - if I like it, the next invocation of the daemon takes that into account and stores in memory. I can tell you now, half of what it suggest to save as learning was either too specific, or too dangerous to save - so review and discard for sure.<br>Here are some details if you want:<br>After any kickback cycle, if the deltas look generalizable, the bot posts a sentineled comment:<br>📚 Captured learning candidate<br>Rule:<br>Why:<br>How to apply:<br>👍 = save · 👎 = discard · edit before reacting for a partial save · 7d no react = drop
daemon/lib/learning.sh polls the reactions API on that comment:<br>👍 writes the rule directly to brainstorm-memory/principles.md - no .proposed, no graduation step. The 👍 is the curation. It also writes a feedback_kb_.md into auto-memory and adds the index line.
👎 hashes the rule into state.json.kickback.rejected_learnings so the same proposal can’t come back.
Edit-then-👍 supports partial saves - the reactions API is independent of the comment body, and the handler re-reads the post-edit text, tolerating a missing Why: or How to apply: line.
No reaction for seven days and it drops.
Expanding to All Steps
Why...