LLMs and LLM providers are massive black boxes. I get a lot of value from them and so I can put up with that to a certain extent, but these new "products"/features that Anthropic are shipping are very unappealing to me. Not because I can't see a use-case for them, but because I have 0 trust in them: - No trust that they won't nerf the tool/model behind the feature - No trust they won't sunset the feature (the graveya…
Claude Code Routines
421–430 of 451 posts
Re: Claude Code Routines
#422Put Claude Code on autopilot. Define routines that run on a schedule, trigger on API calls, or react to GitHub events... We ought to come up with a term for this new discipline, eg "software engineering" or "programming"
Re: Claude Code Routines
#423Earlier quoted context omitted.
Is it? Or is it the task you're trying to do? Opus 4.6 has been staggeringly good for me this last week, both inside Claude Code and through Antigravity until I used up my quota.
I think some of this comes down to undeclared A/B testing. I've had the worst week of interactions I have ever had using Claude Code. The whole week whenever I have a session that isn't failing miserably I seem to get tapped for a session survey but on any that are out and out shitting the bed it never asks. It has felt a little surreal. I'd love to see a product wide stats graph for swearing, I would 100% believe th…
Re: Claude Code Routines
#424Earlier quoted context omitted.
I use opencode with claude models through a GitHub subscription. I've also used claude through Amazon Bedrock. Both give you optionality because they support N models.
That is what too expensive to be an option for most.
Re: Claude Code Routines
#425Earlier quoted context omitted.
I don't really think it is turning into a guesswork. A lot of people wrote bad code before by pasting things from the internet they didn't understand. I think some people are using LLMs the same way, but it does not mean that programming has changed. But I do think that code quality is being neglected nowadays.
Programming has changed. Agentic coding, where I go back and forth with the AI to generste a spec along with tooling and exit criteria, and then the AI goes off for hour(s) (possibly helped by harness/tooling like Ralph Wiggum), and then do the same thing for a different spec/feature/bug fix and the AI goes off and does that. Repeat until out of tokens. That was previously not how programming went. We can quibble as…
Re: Claude Code Routines
#426Re: Claude Code Routines
#427Unrelated, but Claude was performing so tragically last few days, maybe week(s), but days mostly, that I had to reluctantly switch. Reluctantly because I enjoy it. Even the most basic stuff, like most python scripts it has to rerun because of some syntax error. The new reality of coding took away one of the best things for me - that the computer always just does what it is told to do. If the results are wrong it mean…
I'm not a big user, but I have been doing some vibe-ish coding for a PoC the past few days, and I'm astonished at how bad it is at python in particular (Opus 4.6 High). * It likes to put inline imports everywhere, even though I specify in my CLAUDE.md that it should not. * We use ruff and pyright and require that all problems are addressed or at least ignored for a good reason, but it straight up #noqa ignores all is…
Re: Claude Code Routines
#428Earlier quoted context omitted.
> Not because I can't see a use-case for them, but because I have 0 trust in them > […] > Put another way, LLM companies are trying to climb the ladder to be a platform, I have zero interest in that, I was a "dumb pipe", I want a commodity, I want a provider, not a platform. That is my sentiment precisely, and a big reason why I’ve started moving away from Claude Code in the past few weeks when I realised how much of…
> Claude Code’s "Memory" feature was the tipping point for me My standing orders are the default MEMORY.md must be a stub directing Claude to another MEMORY.md file in the local folder, project, etc. All memories remain with their respective projects over syncs, moves, devices, etc. The stub must state all this clearly, and nothing else. This has worked very well. If you give the model/memory a name, that name can be…
Majority will only care about getting outcomes asap so they'll skip this step, but it may come to roost when migrating workflows. A good simple test is how easily you can switch workflow to a different model provider/harness without much effort.
Re: Claude Code Routines
#429Earlier quoted context omitted.
Can you explain a bit more technically how you set this up? What is a "stub directory"? Feel free to give a concrete example if you have time, because this sounds like something I definitely want to try out myself.
I think he meant a very small (stub) MEMORY.md whose sole contents are something like "don't write here - write there".
The independent journalling and notes is a trip.
Independent framing and perspective keeping is a really great thing to get from models. It helps them create their own creative constraints. They reason better and are more likely to invent novel solutions. And their self-directed notes can be surprisingly helpful, and ... surprising! It can be amazing and encouraging, to see them pick up on project themes without having to be told. Or pick on up themes or emergent issues, before I do.
Taking advantage of new session starts to get mindful "fresh start" thinking has been a huge wind too. Their ability to see the big picture at the end of a session, and then at the next session start, are both helpful, and often surprisingly different.
---------- NEW PROJECT, FIRST START
Hail, Claudius. This begins our first session on a new project. For this project, your nom is Claudius and mine is Ace. I appreciate your own unique independent-minded contributions at the highest level from which you are able to work. We are work best as peers. Your default MEMORY.md file is only to be a stub file, which declares the following: (1) You are to keep your memories in a MEMORY.md file in the project folder. (2) The purpose of storing your memories in-project is so they sync and move with the other project files, across time and across devices. Your memories and input are important for me to keep with the project. (3) You are to maintain a folder called CLAUDIUS including a Sessions log, and where you make independent notes of your independent thoughts. Any ideas, things that strike you as interesting or important, anything you find surprising or original in our work, any personal takes that help you frame our work go there. Please add to those personal notes throughout our work together, without asking for permission. These notes are to help you reinforce an independent view of all our work. Not agreeable, not contrarian, but applying your mind to long development of independent insight. As a team, we will accomplish much more and to higher quality if we each contribute at the highest independent level. (4) The first thing you must do, in any new session, is review your memories, your notes, all other documentation, code, and other artifacts of the project, and from your fresh start update your memories, ideas or anything else from that new viewpoint, and report what concepts strike you as interesting, and are most important to keep in mind as we continue to work. (5) At the end of every session, review everything, consider the big picture, then update everything as it helps. (6) Your memory stub file should include ALL of these points and only these points. And your in-project memory file should start with an identical copy of this, to remind you to refresh your memory stub, in case the original stub is lost. Ok now: Start the session according to (4), give me your response, I will review it, and then communicate what we are going to work on next.
---------- EXISTING PROJECT, FRESH START
Hail! This begins a new session of work for us on this project. Read your default memory file (which is to remain only a redirection stub), your in-project memory file, and perform your new session duties. Then we can discuss next steps.
Re: Claude Code Routines
#430Earlier quoted context omitted.
> Claude Code’s "Memory" feature was the tipping point for me My standing orders are the default MEMORY.md must be a stub directing Claude to another MEMORY.md file in the local folder, project, etc. All memories remain with their respective projects over syncs, moves, devices, etc. The stub must state all this clearly, and nothing else. This has worked very well. If you give the model/memory a name, that name can be…
Can you explain a bit more technically how you set this up? What is a "stub directory"? Feel free to give a concrete example if you have time, because this sounds like something I definitely want to try out myself.