I ran the same utcnow migration twice: a local 27B I babysat, and an agent that could run the tests

The task was the same both times: replace 63 calls to datetime.utcnow() across 22 files in a Python service, keep the comparisons that assume naive datetimes working, and leave the tests green. I read both diffs the same way, hunk by hunk. The first approach was local. Qwen3.8-27B at Q4_K_M on a 3090, driven by a shell script that handed it one file at a time with twenty lines of context, no tools, nothing it could run, generation holding around 31 tok/s. The work list my regex built had 58 of the 63 sites, since five sat inside f-strings and default arguments, so that gap is mine and not the model's. Of the 58 rewrites, 4 came back as datetime.now() with no timezone, which is quietly wrong. Three tests failed and it took me forty minutes of diff reading to find which edits caused them. The second approach was an agentic run on a clean checkout of the same commit, allowed to run pytest itself after each batch of edits. It started from a plan I approved that covered the whole file set, so all 63 sites were in scope. It made one bad change in a test fixture, the next run caught the failure, and it repaired that itself. Two edits were still left for me by hand, both where the naive comparison was doing real work. The diff I read second came out of verdent. What one trial cannot tell me is how much of the gap is the model and how much is just a test runner in the loop. submitted by /u/CounterNo1081 [link] [comments]

Related

• I built a local Ollama-based CLI coding agent that can edit files, run tests, and retry on errors
• I built a desktop agent for Ollama — reads files, runs commands behind permission gates, vision + image gen, all local (MIT, open source)
• A local AI agent that instantly maps your entire codebase and finds/fixes bugs without leaking your code to cloud model providers.

Source: r/ollama | 2026-08-23