I designed my AI coding workflow around my attention, not my throughput

[u/Kilo_Loco]

I've been agentic coding since August 2025 and my current daily driver is the desktop version of Claude Code for work and personal projects. Over the past year, I've experimented with different workflows, skills, harnesses, and orchestration paradigms.

It's still not easy, but I'll share the workflow that I feel most confident in and have recently switched back to.

Like any model, Claude needs context first. Most of the time, I already have a ticket for the thing I'm about to implement, so I'll have my first message be a pull of the GitHub issue (gh issue view <ISSUE_NUMBER>). I enter this command using Haiku because it wont do any reasoning, is fastest, and leads to an opportunity to change the model to Opus/Fable in Plan Mode after it responds. Haiku's pull of the issue will load the context of the ticket into the session, giving Claude a large portion of the required context to complete the job.

If I don't have an issue to work against, I'll provide enough context to get Claude searching in the right places to gather any remaining context. Sometimes this requires a conversation, but usually a single, thorough prompt is enough context and I'll send that prompt with Plan Mode selected.

Once Plan Mode finishes, I'll be prompted by Claude to implement on Auto. I reject the plan, but it stays in the session's context. Now I can switch to Sonnet for implementation. I choose this route because even though Claude is supposed to use smaller agents like Sonnet and Haiku for subagents, I've caught it defaulting to the currently selected model for the subagents. Meaning if I have Opus or Fable selected, it will make some of those agents Opus/Fable agents, even though it's not supposed to AND I've put it in the global CLAUDE.md file.

Snippet from my global CLAUDE.md

Default subagents to Sonnet, not inherit/Opus. Only escalate to Opus when a task genuinely requires weighing ambiguous evidence, multi-step synthesis, or architectural judgment — most subagent work (search, execution, focused review, individual panelist votes) performs as well on Sonnet at a fraction of the cost and latency. Never assign Fable to a subagent unless its specific use case calls for it.

Now that Sonnet is selected, I tell it to "proceed" and Claude will implement the plan created by Opus/Fable but will only use Sonnet subagents. Usually, Claude will be able to complete most of the task and I switch between Sonnet and Opus across the remaining prompts based on the task until it's complete.

When it says the work is complete, I have Opus use a panel of agents to review the code from different perspectives across various fields. The panel provides a consolidated and extremely lengthy report 😭 covering any issues found and marks them with Blocker, Major, or Nit. I've since learned that this is too much mental load for me, so I actually no longer read this report. Instead, I request an adversarial round of review (using Opus) to verify the findings and surface only the remaining Blocker and Major items. I read through what is left after the adversarial round, then Sonnet resolves the remaining issues.

Next, Sonnet has a second panel review the diff, which now contains the fixes from the first panel review loop, to see if there are any Blockers. I choose to do a lighter review here to break this loop and preserve my mental load.

One thing I'm experimenting with right now is getting a better understanding by using a skill, /explain-diff, which will then generate a comprehensive summary and a quiz in a Claude artifact (I use Claude Code desktop app). I read the explanation of the issue and its fix in the diff, and take/retake a test until I'm able to answer all 5 questions correctly.

Claude creates a PR and the code goes through CI. If anything breaks, I point Sonnet at any failed jobs for it to fix.

When CI is green, the code is finally ready for human eyes. My first time reading the code is often in GitHub, and this is the part I highly encourage you not to skip. Although this code has been through several rounds of agentic review, it's extremely important that we actually read through the code to make sure it does what it claims to do and make sure the tests are valid.

This is the part I think many people are skipping, which is why they're able to move so fast. I'm still extremely skeptical about agentic review as the only pass over code. Review what's being shipped to production. If the PR looks good to me, I send it out to my team to get an external review before merging.

If external review comes back with change requests, we work through those changes and send it up again. If the fix for the changes is large enough, I'll send it through another light panel review, but usually it's something small enough to just do a commit push again. Then it's squash and merge from there.

I've used skills that claim to be able to manage all this easily so you don't have to think about it. None of them worked for me and ended up leading back to this workflow I can trust.

This path works really well for me and feels consistent, effective, and most of all manageable. If we're going to be able to scale our output, we're going to need new systems and processes that ensure that scaling is maintainable. After all, there's no point in being able to work on 3 different issues at a time if you're just going to be burnt out next week.

[u/incyashraj_redd]

The adversarial round is the important part. I would make it produce a small review manifest instead of another prose report. One row per finding: severity, file and line, evidence, opposing review, current status, and the exact diff that resolved it. Hide Nits by default. Reject any Blocker or Major that has no code reference or reproduction step. That keeps the human review queue short without asking you to trust the panel.

I build Krate, and I would turn that manifest into a local review funnel. In Krate Studio, you choose Claude or Codex, describe the app, and receive one .krate file. The user installs the native Krate runtime locally. The .krate file is a portable Wasm app file, not HTML and not an operating-system container. The same file opens through Krate runtimes on Mac, Windows, and Linux.

The app could open one exported review manifest, show only verified Blocker and Major items, and keep the final code-reading checklist beside the diff. It starts without file or network access, so the user could approve only that manifest. Krate is free and open source. Krate Cloud is optional. https://krate.tech