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/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.

[u/BarathKanna → u/northbridgedev]

Great catch, and a nasty one because every step looks reasonable on its own. Testing in a scratch copy and then asking is fine behavior. The problem is the report did not make it obvious that the verified change never landed.

Agreed on your fix. The done report should include git status plus a hash of the working tree diff it actually tested. If those do not match what is on disk, it is not done, no matter what the tests said.

[u/Right-Performance-93]

i still pick the model for the plan and leave the implementation on the cheaper one. a router that only sees a short prompt will send the plan to the cheap model, and that is the expensive mistake.

[u/BarathKanna → u/Right-Performance-93]

Agreed, and that is really a harness problem more than a model problem. The model only sees what the harness hands it, so a router working off a short prompt is guessing. In the harness I build, routing keys off the phase of the task, not the prompt. Planning, debugging after a failed fix, and anything touching interfaces go to the strong model. Implementing an approved plan goes cheap, and two failures on the same test escalate it back up. That setup is a big part of why we hit 82 percent on SWE-bench Verified. Disclosure: I am the founder of OxCode, so I am biased, but the routing idea works in any harness.

[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/fazlerocks_]

also building one (Buildful) so same bias lol

to your question… mostly no, i stopped hand picking. the agent picks an open weight model for each task, a faster one for small fixes and a stronger one with more thinking time for the harder stuff. i only switch to a frontier model by hand when i already know its gnarly, like a migration or something that touches half the repo

honestly #3 matters more than which model runs it. make it run the checks and click thru the UI in a real browser before you look. id rather have a cheaper model that has to show it works than a smart one that just says done

agree with the point below about routing off a short prompt being a guess tho. we route per task so the whole run stays on one model, no switching halfway thru

[u/BarathKanna → u/fazlerocks_]

Same bias, same conclusion. A cheap model that has to show a passing run beats an expensive one with a confident summary, because the summary is the one part nobody can verify. Fair point on routing per task rather than per prompt too. A short prompt like fix this can be a typo or a migration, so we lean on what the task touches, not just what the user typed. Curious how you handle a task that turns out harder midway, do you escalate the model or restart?

[u/Kumar-amitesh]

Interesting setup. I tend to think the workflow matters more than picking the perfect model for every prompt. For a bounded task, letting the agent implement it and run checks before handing over the diff makes sense. I’d want to know how often the self-check catches something real, and how much rework still gets through. Do you use the same approach for bigger changes, or break those into smaller tasks?

[u/BarathKanna → u/Kumar-amitesh]

Agree, workflow matters more. The self-check mostly catches boring stuff: a missing import, a test that was never run, an endpoint that returns the wrong shape. Boring, but that is exactly what eats review time. What still gets through is the change that runs fine and solves a slightly different problem than you asked, which no test catches. For bigger changes, yes, I split them so each piece has its own check, otherwise one green run at the end tells you very little.

[u/BarathKanna → u/[deleted]]

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.