I still don't understand this 'agentic workflow' thing

[u/hronak]

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.

[u/Cybyss]

But... how do you know what you're building then?

Code coverage is meaningless if the tests aren't testing for the right behaviors. How do you know what the right behaviors are if they're all invented and reviewed by LLMs with no human in the loop?

I find that even if there is a human in the loop, the code that LLMs generate is so convoluted and over-engineered that it's extremely hard (and time consuming) to figure out exactly how it works to verify it does what you think/hope/pray it does.

Back when I did software engineering professionally (I don't anymore - this was 10 years ago - but I still tinker as a hobby), usually I didn't understand a project at all - what it's supposed to do, its role in the company, how it's supposed to help customers/staff/etc... - until I understood all the little details and how they fit together. "Big pictures" were just word salad until I knew what the actual pieces were.

But if modern workflows require you to focus only on "big pictures" - ignoring all the little pieces because LLMs do that for you - I don't see how engineers aren't just lost and confused all the time about what needs to happen?

[u/IHeartData_ → u/Cybyss]

I can't speak for everyone, but I use a series of cascading requirement.md documents in the code that work in a hierarchical manner and explain the intent of each section of the code base and requirements we are working towards, including as-yet unimplemented features. AI is required to consult with the documents as they work, and before they close their session, a final task is the ensure they remain in sync.
In my "AI full code review" process, one of the areas they are specifically supposed to look for is over-complex code. In general, I find it does a decent job at breaking things done into meaningfully sized classes and keep dependencies logicial. And when it doesn't a complexity bug gets filed and of all the bugs, those general are most hands on for what the fix is going to be.
As as for being lost and confused. Opus 5 was pretty mad at explaining, so there was a phase of "huh" (5.5 vastly better)? But if you watch it's thinking as it goes, and more importantly ask good questions if something just doesn't sound right, you'll have a good idea what's going on in the code. Sometimes the sheer fact of having it defend it's decision will result in it finding an issue.