Most people run claude code like a smarter terminal. ask for a change. take the diff. maybe run tests. close the session. it works fine. it also wastes most of what claude code can do. what changed was treating the whole repo as the loop. the pieces: persistent or resumable sessions for long-running work CLAUDE.md, .claude/rules/, skills, and notes as project memory and procedures you can read, edit, and diff browser and chrome for real visual review a throwaway html app when markdown or screenshots won't show the interaction hooks, /goal, /loop, routines, scheduled tasks, and workflows for follow-up loops verification before anything counts as done the value is continuity. the project keeps moving across sessions instead of resetting every time i open a new one. a good loop reads the codebase, ships a change, runs the local app, opens the rendered ui, checks an artifact, glances at a pr, updates the notes, runs the smallest verification that means anything, and leaves behind enough state for the next session to pick up cold. none of that is generate-and-stop coding. i keep this in my setup as a standing instruction. global lives in ~/.claude/CLAUDE.md, one repo in ./CLAUDE.md, or make it a skill:

what i want out of it is work i can open up, redirect mid-flight, come back to tomorrow, and check. the loop is what makes all four normal. i use loops across my own work: maintaining parts of my codebase and a docs repo, keeping the article system behind a couple of my sites current, pulling the latest official skill docs so nothing drifts, and catching sentry error alerts and fixing them. a few small apps i use every day, too. at any given time there's a handful going. the rule i hold claude code to: leave enough project state that the next session never starts from zero. this is the jason liu and steipete point. stop hand-prompting. build the loop that does the prompting for you. get your loop on. start small, think big.