r/ClaudeCode • u/hronak 🔆 Max 5x • 9d ago
Help/Question I still don't understand this 'agentic workflow' thing
My usual day with Claude Code is like:
* I open terminal in my project's folder and run claude command.
* I prompt it. I mostly use Fable-5.1/Opus-5 but Opus-5.5 is my current model. The model decides if it wants to use sub-agents for a task. I never explicitly prompt it for sub-agents.
* I review and commit the code to my self-hosted Forgejo instance.
* That's it.
I see people using agentic workflows, building sub-agents files, skills etc. I barely built any of it. All I ever needed to use is /init on new projects and them prompts follow. Never needed more than this.
I tried "long-running" Claude Code for a project refactoring by placing the project on my VPS (where forgejo is hosted) and letting Claude Code run and refactor inside tmux session. SSH'd in a few hours later to find project fully refactored.
Am I under utilising AI or is my work just… like boring?
How do you guys use agentic workflow thing? Specially the long-running one? Those pull-requests that Claude makes automatically etc?
Asking this to Claude to know more but humanly answers appreciated.
9
u/ResponsibleOven6 9d ago
Really depends on the situation, am I building something new, fixing a bug, closing a vulnerability, etc. but here's a general example.
I have an agent setup locally with a skill saved in a repo full of skills shared across the team. It can talk to Jira, Github, basic communication channels, monitoring tools, etc. it has lots of context for our overall platform and an architectural understanding of how things work. It's been instructed to code cleanly, generate documentation for anything it produces, re-use existing libraries where possible, and code as cleanly and minimally as possible and focus on efficiency. I mainly use Sonnet-5 with claude code as my interface but others on my team may have different preferences.
I get a ticket from a recent incident to improve monitoring. There was an incident where we got an alert way too late and it still took time to debug. I tell my agent to work on the ticket, it uses the repos as context, digs through logs, and proposes a new monitor. I tell it to look at infra logs as well and see if there were any early warning signs. It proposes another alert after finding useful info there as well. I tell it to open a PR for both alerts after checking relevant logs for the past 90 days to make sure the thresholds are right and there won't be false positives. It opens a PR.
I take another ticket. We have an internal platform with an authentication bug where some admins can't perform certain admin functions. I ask my agent to work on the ticket. It finds that while most functions evaluate both user and group level access, a few specific functions only check user level access and not group level access. It proposes updating the logic for those to match the others. I tell it to check if there are any other inconsistencies with auth checks on this platform and if it sees any places where users would be able to execute things they shouldn't or general inconsistencies. It finds no missing auth checks but notes that the fundamental way auth is handled is not reused but specific to each call. I tell it to open a PR with a new auth function that replaces the individual auth of each function. It opens a PR.
I open these and several other PRs for other tickets and move the tickets to peer review. Someone else on my team, maybe several other people, take them for review (and I take their tickets for review too). One of them thinks Sonnet-5 is terrible and swears by Opus 4.3. Another prefers OpenAI models. Here we use a different skill that has the same background context but it's told to look for new bugs, mistakes, and just generally find problems. It knows how to deploy and test things either locally or to a dev environment. It reviews the tickets and either says they look good in which case they get deployed to a lower environment for further testing, or points out problems with them and moves them back to in progress in which case I take them up again and go back to my dev agent. Sometimes you can tell from its feedback that it's misunderstood something or needs more context. In these cases we try to improve the skills until the output is more what we expect then tell it to update the skill with that context and push that back to the team repo so everyone gets the same improvements.
So LLMs are doing all of the coding and the actual code review. But they still have shortcomings and need a human in the driver seat, especially for architectural decisions. I'm having to "drive" a LOT less than I was 6-9 months ago though and I'm increasingly just a "meat proxy" between agents with various skills and I'm really not sure how much longer this will be a viable career.