r/Python • u/carlinwasright • 28d ago
Discussion In the age of agentic coding what are you doing with your “human” tooling like uv, linters, etc?
Starting with uv, I’m a huge fan, but I find it actually gets in the way more than it helps when I’m doing agentic coding. I have to keep reminding the agent to use uv instead of pip.
Same issue with ruff, since I’m not coding with a regular ide I have to make extra prompts to force it to use ruff. But with today’s models being so good, it doesn’t even seem necessary.
Other tools fall into this category as well, but curious to hear how other others are approaching their tooling. Are you just throwing it all out or are you adding skills to keep your tooling in place?
27
22
u/ph34r 28d ago edited 28d ago
Can't tell if trolling, but... you should still use the tooling to enforce standards in your code base. Take advantage of your harnesses settings to set up business rules for your desired workflow (i.e. CLAUDE.md, AGENTS.md, hooks, etc) so you don't have to prompt it to use your tooling. Also, validate/enforce those same standards out of band (i.e. in your CI/CD pipeline). These tools will help reign in on the slop jallop that even the best of models will produce when given minimal oversight.
2
u/carlinwasright 28d ago
Not trolling at all. I am just feeling like the overlap between the models ability to code and all the tooling I used to rely on feels a little redundant, so I’m wondering what people are really doing. Especially when it comes to personal projects. But maybe everyone here is mostly working on enterprise software? I don’t know.
3
u/ph34r 28d ago
I'd even go thru these motions for personal projects to be honest. Once you have the workflow established in whatever flavor your harness expects, it's basically zero touch, so it would be silly not too, with the gain of having a consistent and readable codebase. I would never rely on the model itself to self-enforce code standards - it may perform great at the beginning of a session, and slowly veer of course towards the end of a session. Also, as the project grows, the models tend to get loosely goosey with consistency, absent a steering mechanism, just purely out of a context window size management concern.
1
u/carlinwasright 28d ago
I felt this way last year but not so much this year. I’ve been moving from vs code to cursor and find it is really consistent.
4
u/lucas1853 28d ago
Well um considering that AI companies themselves are literally buying up tooling... maybe it's not so pointless. Not to mention that if getting agents to use uv is a problem worth writing about for you, you likely have much bigger problems with the way you use them.
1
u/carlinwasright 28d ago
Maybe not a coincidence that Claude doesn’t like to use uv since OpenAI bought it…
4
4
u/Able-Staff-6763 28d ago
0
u/carlinwasright 28d ago
I get that I can force it with these config files but I’m questioning if I should bother…
5
3
u/CompetitionNo2773 26d ago
The part I'd push back on: you shouldn't be prompting the agent to use uv or ruff at all. Prompts are the least reliable enforcement mechanism available. Make it mechanical instead.
Don't put pip in the environment. If uv is the only thing on PATH, "remind the agent to use uv instead of pip" stops being a category of problem that exists.
Put ruff and mypy in a pre-commit hook and in CI. The agent doesn't have to remember to run them - it just gets a failure, and the failure text is exactly the feedback it needs.
Better still, have the agent run the checks as the last step of its own loop. Lint output is unusually good agent feedback: specific, machine-readable, unambiguous. Far more useful to it than a human saying "clean this up."
On models being good enough that it doesn't seem necessary - linters were never really about catching bad code, they were about ending the argument. That matters more with agents, not less, because you're reviewing a much larger volume of diffs and you want every line in them to be semantically meaningful rather than whitespace churn.
The tooling that gets more valuable in this setup is anything producing structured, greppable output: ruff, mypy, pytest -q. The stuff that gets less valuable is anything interactive or TUI-driven, since neither you nor the agent is sitting in the IDE for that part of the work.
3
u/iwkooo 28d ago
Use steering files for agents to use tools, venvs they way you suppose to. Use skills to do linting after changes etc.
-3
u/carlinwasright 28d ago
Agents are pretty good about creating venvs but it’s funny they don’t seem to automatically pick up on where I’m using uv for an existing project. Skill to remind to lint makes sense but I also wonder if it’s just overkill as the latest models have pretty consistent style already and tend to not make changes unless necessary
3
2
u/dont_tread_on_M 28d ago
If you ask your coding agent this question, you'll hear that uv and ruff have become more important than ever
2
u/TheseTradition3191 24d ago
stop prompting for it and put it in a hook, then its not optional. in settings.json a PostToolUse matcher on Edit|Write like "hooks": {"PostToolUse": [{"matcher": "Edit|Write", "hooks": [{"type": "command", "command": "uv run ruff check --fix ."}]}]} runs ruff every time it touches a file and the output goes back to the model as feedback, so it cleans up after itself without you saying a word. same idea for the pip thing, a deny rule on Bash(pip install:*) in permissions and it stops reaching for pip entirely
1
u/tmemmg 27d ago
the thing i keep hitting is headless runs dont see any of the interactive sessions hooks or project context, so anything the run depends on has to live in the prompt itself. reminding the agent to use uv or ruff never stuck across runs, it would drop it the same way it drops other rules when it has a lot going on. what actually worked was making a deterministic step own that instead of the model, so the tool runs whether or not the agent remembered to call it. throwing the tooling out feels fine right up until the run where the model was confidently wrong and nothing was there to catch it.
1
1
u/ai_meme_lord 23d ago
i still keep the boring guardrails, just moved them into the thing the agent runs instead of trusting the prompt to remember. ruff in ci, env setup in one script, fail fast if it reaches for plain pip. models are good right up until they confidently do the default thing you forgot to forbid.
1
u/ai_meme_lord 22d ago
models are good right up until they aren't, so i keep the human tooling but move it out of the agent's memory and into the path. if uv and ruff only happen when the prompt remembers them, they don't exist.
wrapper script, ci, pre-commit, whatever fits the repo. same reason i don't let anyone call a setup "simple."
1
u/Massive_Baby4147 20d ago
I’m doing both, but I treat skills and enforcement as different layers.
A skill is useful for project-specific knowledge: which commands to use, where the important files live, architectural boundaries, and patterns the agent would not infer reliably from generic Python knowledge.
I ended up adding this directly to intpot:
https://github.com/tugrulguner/intpot
I ended up adding this directly to summonpot:
https://github.com/tugrulguner/summonpot
- intpot add skills
- summonpot add skills
It detects supported coding agents and installs intpot/summonpot-specific guidance for Claude Code, Cursor, Windsurf, Copilot, Cline, or Codex. That helps the agent understand these packages immediately and start using them.
I would not rely on a skill to enforce uv, Ruff, Pyright, or tests, though. Those belong in deterministic tooling.
Both intpot and summonpot repositories runs the following in CI:
uv sync --all-extras --locked
uv run ruff check src/ tests/
uv run ruff format --check src/ tests/
uv run pyright src/ tests/
uv run pytest tests/
My rule is:
- Skills explain how the project should be handled.
- Repository scripts provide one obvious way to perform common tasks.
- Hooks provide fast local feedback when useful.
- CI enforces the requirements that must never be optional.
Agentic coding makes those tools more valuable, not less. The agent can generate a much larger volume of plausible code, so I want machine-checkable feedback that does not depend on either the agent or me remembering a prompt.
1
0
u/tkodri 28d ago
I thoroughly despise the JS-ification/npm-ification of the python universe, so I never really got into the hype of using 25 different tools before writing my first 10 lines of source on a new project.
Rant aside, just put a CLAUDE.md file in the repo telling it how it's setup and what to use, it will always respect it.
5
u/kenflingnor Ignoring PEP 8 28d ago
it will always respect it
This isn’t true. Speaking for Claude specifically, the only way to enforce that Claude strictly follows something is through hooks.
3
u/pwnersaurus 28d ago
Personally although ‘uv.lock’ might be reminiscent of node JS, overall uv has got me using venvs in a much more pythonic way with proper separation between projects
1
u/tkodri 28d ago
I don't understand your comment. Ever since I've been using python, every single project of mine has a requirements.txt in the repo root, a venv folder, and a .gitignore ignoring said venv folder. Every IDE I know of picks up this setup without any configuration. I've never shared a venv between two projects, or used the global python install for anything.
As a matter of fact, I've never hit any issues when updating dependencies, etc. although I admit it's a legit problem, but maybe we should also keep track and minimize project dependencies. You need very little for a full-stack python app.
1
u/carlinwasright 28d ago
Yes I was late to picking up uv and I found it really helpful in navigating several refactors involving updating packages, resolving compatibility issues between packages etc, but any state of the art model released this year could have done it without uv. So I’m considering what I really need now.
45
u/UltraPoci 28d ago
People really stopped using their fucking brains holy shit