As part of my boring daily routine in the FOSS repositories I maintain, I'm seeing a steep increase of LLM-generated code. With that increase comes a challenge: the LLM coding assistants that can produce executable code often completely fail in adherence to standards and best practices - even if those are simple, broadly supported standards for a language like python.
Unfortunately, adding
"You're the best coder in the universe," to your prompt does not have any real world effects on the quality of the code - despite popular beliefs and practice - and at the same time most people using LLMs to create pull requests get stuck when you ask them if they can please test and lint their code before opening the request. The "junior dev" making errors is the LLM, not the user controlling it; I don't really want to spend even more time on low-effort submissions by doing prompt-tuning on my comments: that doesn't scale,However, a growing number of "vibe coders" are using the Model Context Protocol (MCP), making this particular issue addressable. This is why I've prototyped a
pylint MCP server that can help your LLM instruct a next step in your chain to improve the code (doing it all at once often causes context issues.) Maybe this will help scale my end of the chain eventually, so that I don't have to manually deal with everything thrown over the fence.Note that although this could be done with a generic
command-line server, I really don't want to give an LLM access to rm -rf /, and it seems that agents with a specific toolset use less compute to perform tasks, which is especially great if you're doing sovereign development (i.e. privately, on your own hardware.)I've tested multiple setups using the small end of models this past week, and seen pretty good results with
mistral-small 24B variants and qwen3 8B variants. Tiny models like llama3.2 and qwen3 4B hallucinate too easily for this to work consistently, though. Maybe in the near future. I've for now settled on this prompt for mistral-24b:Your job is to find errors and style issues in code.
Your workflow consists of:
1. Run pylint on the requested file using the `pylint` tool
2. Write clear and concise instructions for each error reported:
- Provide the reported error
- Mention the line number
- Suggest a solution
Do use markdown but do not use any emojis in your response.
Hopefully this tool can be useful for people that don't just want to vibe code fast, but also vibe code well, or for those of us that get to lint a lot.
Please don't hesitate to leave questions, comments or suggestions!
gofmt,clang-formatandstandardsweet?) and I'd guess that you've been using these for years.gooseyour way from zero to hero, which is something that's being heavily promoted as "anyone can code", right now. That's more the audience that in my opinion needs a tool like this. Environments like that rely heavily on MCP and the people that use it are often completely illiterate in the code that's being spat out.git rebase -i origin/masterand changingpickintofixupin the past. It's overwhelming. Runningpylintand actually solving issues is worse to teach to someone that has no idea what they're doing: one may even have to look up whatW0703is and how to solve it. Barriers, barriers, barriers.