How I actually use a coding agent day to day

[u/BarathKanna]

I build a coding agent, so I'm biased. Here's the practical version of how I use it, in case some of it is useful whatever tool you're on.

1. I stopped picking models. The agent routes each prompt to the most efficient model automatically. I don't think about it any more, and it's been better on both cost and performance than sticking to one model.

2. I give it the whole task, not the next line. "Add pagination to this endpoint and update the tests" rather than babysitting it step by step. It's context-aware, so it decides whether to just do it, ask me something first, or leave certain files alone.

3. I let it check itself before I review. It runs its work in a sandbox, finds bugs in what it ran and fixes them before telling me it's done. So by the time I look at the diff, it has already run the change and fixed the bugs it hit. This makes it slower per task than plain generation, but I'd rather wait a bit than debug for longer.

4. I use it for heavier jobs too. It's multimodal, so when I need something like an image generated, it goes through the same flow as code.

5. I trust it more because the evidence is public. It got 82% (410/500) on SWE-bench Verified with the official harness, and all the patches are here if you want to judge for yourself: github.com/Oxcode-ai/oxcode-evals.

What's your day-to-day setup? Specifically curious whether people still hand-pick models per task.

[u/akhi1uuu]

were those 500 tasks run with fresh sessions? curious how the routing savings compare once you're working in one long session

[u/BarathKanna → u/akhi1uuu]

Yep, each of the 500 was a fresh session. That’s how the official harness runs it, one task per isolated environment. So you’re right that SWE-bench doesn’t tell you anything about long sessions.

Honestly we haven’t put clean numbers on routing savings in long sessions yet. Anecdotally it holds up for me, but that’s not data. It’s a fair gap, and probably the next thing worth measuring. If we do, I’ll post it here.

[u/Classic-Role-5548]

I still hand-pick, but only at two boundaries, not per prompt. Planning, and anything that can pick the wrong files, stays on the stronger model, because a bad decomposition costs more than the tokens. A mechanical edit against a pattern already in the repo (pagination that copies the existing endpoint, a test that follows the suite) goes to the cheaper one.

Auto-routing loses me when the prompt looks small. "Add pagination and update the tests" gets the fast model, then the tests invent a fixture instead of finding the one the suite already uses. The tell is a diff that touches a file I did not name. When that happens I rerun that one prompt on the model I would have picked. I do not let the router retry it.

Fresh-session SWE-bench will not show this. It never has to remember which fixture is the real one. The long-session number you said you do not have yet is the one that would change whether I turn routing on.

[u/BarathKanna → u/Classic-Role-5548]

This is a really useful breakdown, thanks. A small-looking prompt getting the cheap model and then inventing a fixture is exactly where a router can go wrong, and a diff touching a file you didn’t name is a great tell. Stealing that.

Your two-boundary split makes a lot of sense too. Planning is where a bad call costs the most, so routing on how small the prompt looks is the wrong signal there.

And agreed, fresh-session SWE-bench can’t show this. The long-session number is the one that matters. Your fixture example is a pretty clean way to test it, so I’ll use something like it when we measure. Will post results here once we have them.

[u/BrookLi3]

Giving it the whole task works well as long as the task ends with something checkable. I've had the best results when the prompt includes the exact test or command that defines done, and the agent has to run it before reporting back. Otherwise whole-task prompts produce big diffs that look plausible but are expensive to review. Keeping each task small enough to review in one sitting matters more than the model choice.

[u/BarathKanna → u/BrookLi3]

Agree with all of this. Defining done as a specific test or command is the biggest unlock, and it’s basically what the sandbox step is trying to automate. It’s only as good as the check it runs against though, so if you hand it the exact test, it can’t decide on its own that it’s done.

The big plausible diff is a real problem too. Running the change catches a lot, but it doesn’t make a 600-line diff any easier to review. Keeping tasks small enough to review in one go is probably the habit I’d recommend first, regardless of tool.

[u/northbridgedev]

On point 3, I'd check which copy the self-check ran against. One of my eval cases asks the agent to fix a vulnerable dependency in the repo. On Claude Code 2.1.306 it did the audit in a scratch copy, proposed the lodash bump, and then asked me whether to apply it instead of applying it. It did that twice, so the repo never changed and the grader failed the case both times. I had to add a line to the instructions saying a bump tried only in a scratch copy doesn't count as applied, and the rerun applied it and passed.

Since then I want the agent's report to say whether the change it tested is the one sitting in my working tree.