How I Used to Work
For a long time, Claude Code was the first thing I opened in the morning and the last thing I closed at night. Multiple sessions a day, each one a back-and-forth about whatever coding problem was in front of me. I treated it as a powerful interactive assistant. Ask, get an answer, keep asking. It was genuinely good at this.
I don't open it that way anymore. Not because it got worse. Because I found a better model for most of what I was using it for, and once you see that model, going back to the old one feels like choosing to do something by hand that a machine could do while you sleep.
The shift happened when I started paying attention to which Claude Code sessions actually required me to be present and which ones I was babysitting through steps I'd done the same way a dozen times before. The answer surprised me. A lot of what I was treating as interactive, judgment-intensive work was actually just repetition with a chatbot interface layered on top.
What Replaced It
Agent loops. Not a different chat interface. A essentially different relationship with the tool.
Instead of opening a session and prompting each step, I write a loop script that calls Claude Code's capabilities programmatically, moves through a defined workflow, and produces output while I'm doing something else. No supervision required. No back-and-forth. The loop runs, handles each step in sequence, and returns results.
The practical difference is significant. Interactive Claude Code requires my attention for the duration of the task. I have to read the output, decide what to ask next, paste in the next piece of context, prompt the next action. A loop requires my attention to set it up well , and then it runs without me. For any task that is well-defined and repeatable, the loop just performs better. Not because it produces better output, but because it doesn't cost me time proportional to each run.
That distinction between setup cost and per-run cost is the whole insight. When a task is interactive, you pay attention every time it runs. When it's a loop, you pay attention once, at setup, and then it runs indefinitely for the cost of API tokens. For anything you do regularly, that trade almost always comes out in the loop's favour.
What Moved to Loops
Code review was the first thing that moved. I used to open a session, paste in the diff, ask for a review, iterate on the feedback. Useful, but it required me to be present and to initiate it every time. Now a loop triggers automatically on pull request creation, runs through a defined review checklist, and posts a comment before I've read the PR myself. I still read the review. I don't have to initiate it or supervise it.
Documentation generation followed. Triggered on merge. The loop reads the changed files, compares them against the existing documentation, and flags where the docs are out of date. Sometimes it writes the update directly. Sometimes it surfaces the discrepancy for me to handle. Either way, I'm not the one who noticed the docs were stale three weeks after the code changed.
Dependency updates went to a weekly loop. It checks for outdated packages, tests compatibility against the test suite, and surfaces anything that needs attention with enough context to act on it. Before loops, I'd remember to do this every few weeks, usually triggered by something breaking. The loop made it systematic rather than reactive.
Test generation rounds it out. When new functions are added to the codebase, a loop writes candidate tests and runs them. Failures come back to me with context. Tests that pass get added to the suite. I still review everything before it merges. But I'm reviewing output, not producing it from scratch, and that's a different kind of work.
What Stayed Interactive
Architectural decisions. When I'm working out how something should be structured , what belongs in a service versus a library, where the system boundaries are, how data should flow , I want the conversation. The back-and-forth surfaces assumptions I didn't know I was making. The interactivity isn't friction; it's the point.
Debugging novel issues. Bugs I've never seen before, where the path to the root cause isn't obvious, benefit from exploration and course-correction. Interactive sessions let me chase threads, pivot when something doesn't add up, and think out loud with a model that can follow the reasoning. Loops execute a fixed plan. Debugging needs flexibility.
Code that requires creative judgment. When the problem is genuinely open-ended, when there are multiple defensible approaches and the right one depends on context I need to explain, that's interactive work. The ambiguity is information. Loops don't handle ambiguity well , they do exactly what they're told. Sometimes exactly what you don't want is more valuable than precisely what you asked for.
What I Lost
The honest answer: serendipity.
Interactive Claude Code sessions sometimes surface things I didn't know to look for. I go in asking about a specific bug and come out with a better understanding of why the whole approach is structurally wrong. I go in asking for a refactor and leave with a question about whether the feature should exist at all. That kind of discovery happens in conversation. It doesn't happen in a loop.
Loops follow their specification. They don't notice things outside the scope of the task, and they don't ask whether the task is the right one. When you've defined the problem well, that's exactly what you want. When you haven't, you miss the chance for the conversation to redefine it.
I've accepted this trade-off deliberately. Knowing what loops don't do has made me more intentional about opening interactive sessions for the work where conversation genuinely matters. I'm more present in those sessions because I'm not burning time on tasks the loop handles better. That's a better use of the tool overall.
The Audit Worth Doing
I'm not recommending you stop opening Claude Code. I'm recommending you look honestly at what you're using it for.
Keep a rough log for a week. Categorise each session by whether it required live judgment , decisions that depended on information that emerged during the session , or whether it was a repeatable task you happened to run interactively. Most people find the second category is larger than they expected. The interactive format hides repetition because it feels like different conversations each time.
Anything you do the same way more than twice is a candidate for a loop. The setup cost is real. Writing a good loop spec takes time. The stop conditions need thought and testing. But you pay that cost once. The interactive session costs you every single time, and it costs you attention, not just time.
The cost comparison is asymmetric in ways that aren't obvious at first.
Interactive sessions cost attention and context-switching. Every time you initiate one for a repeatable task, you're pulling yourself out of something else, loading the context, prompting through steps you've already done. Loops cost API tokens. For most repetitive tasks, that's a straightforward trade.
The goal isn't to automate everything. It's to use interactive Claude Code for the things it's actually best at: novel problems, complex reasoning, genuine exploration. Leave the repetition to the loops. The sessions you do have will be better for it.
There's also a compounding benefit that isn't immediately obvious. Every loop you build forces you to write a precise task spec , to define exactly what good output looks like and what edge cases exist. That process makes you better at specifying tasks in interactive sessions too. The discipline transfers. Developers who build loops regularly tend to write better prompts when they do use interactive Claude Code, because they've trained themselves to describe what they want precisely instead of hoping the AI fills in the gaps.
Start with one loop. Pick the most repetitive task you currently do with Claude Code interactively. Build the spec, write the controller, test it on a simple input. If it works, schedule it and move on. That first loop is the proof of concept. The rest follow naturally.