Writing a rules file for an AI agent does not guarantee the agent keeps following it. Running automation pipelines taught me that the rules that hold are rarely the ones you only wrote down. I run a set of pipelines on a VPS: scrapers, rankers, render jobs, bots. Claude Code is how I build and operate them, not a side experiment. One of mine sat silently broken for days because a lock swallowed every failure without a sound. Another one nearly took the whole box down when several browser automations ran in parallel; they run one at a time now, behind a single lock. A parser once read a field at the wrong level of a nested JSON payload and returned nothing for every row. It just looked boring instead of broken, which is worse. None of those got fixed by a stronger line in a rules file. I fixed the JSON one by asserting on real values instead of just checking that a key exists. I cap how often a scheduled job can call a model instead of trusting someone to remember a limit, and I block a run instead of hoping secrets stay out of a repo. Where do you draw that line in your own setups? What do you still rely on a written reminder for, and what have you made the system enforce on its own?

You know this if you run more than one coding agent: six tabs open, three sessions going, and one finished an hour ago without you noticing. I run a string of automation pipelines on one server, scrapers, rankers, render jobs, bots, and Claude Code is the tool I use every day to build and operate them. A cron job on that server once sat dead for days because a lock never released, and it looked exactly like a quiet day until I checked. Another time, a handful of browser automations running at once pushed my box to the edge of running out of memory, because nothing was serializing them. Both were setup problems, not agent problems. Every long running step gets a timeout and a heartbeat now, because silence should read as a bug, not as "it's fine." New agents and models show up every week. What holds up across all of them isn't the agent, it's whether your pipelines have that kind of structure underneath. What's the one rule like that (a lock, a timeout, a naming convention) that you only added after it already cost you something?

There is a command in Claude Code that barely anyone uses: /statusline. It sets up a line at the bottom of your terminal that always shows you what is actually going on. What you can put in it: → which folder and branch you are working in → which model is answering → how full your context window already is → basically anything else you want, even something unrelated like the weather I run Claude Code every day across a lot of different automation projects, so knowing the folder, the branch and the model at a glance matters more than it sounds. Most mistakes do not come from the model being wrong. They come from being in the wrong folder, on the wrong branch, or working inside a context window that is already full. Type /statusline, describe what you want on it, and it builds the line for you. After that you see your actual state instead of guessing it. What is on your statusline?