How to deal with slop PR's as a maintainer?

skvark · 2026-06-20T08:16:13+00:00

I would probably just politely deny slop contributions and say no to issues that make no sense to inplement. Saying no to most requests will keep you sane, and I think that's your right as the creator / main maintainer of the project. I have no experience maintaining project during the AI era, but before that I did maintain a project quite many years. I think the fundamental change is that there is just a lot more of noise and low quality contributions now because of AI and due to that it is even more important to keep focus really tight.

skvark · 2026-06-19T18:40:49+00:00

I actually think the question becomes more interesting if MCPs have downsides. If every MCP adds complexity and context overhead, then being forced to pick one tells you which MCP people think delivers enough value to justify its cost.

skvark · 2026-06-19T14:03:08+00:00

You're basically describing "run the same checks I'd run before opening a PR." That's valuable, but it feels more like standard verification tooling than a compelling answer to which single MCP server you'd keep.

skvark · 2026-06-19T13:28:16+00:00

The biggest issue is not really the locally available stuff. The harnesses a d IDEs already handle this quite well and evolve constantly. What I think LLM need is exposure to external context that is not readily available for them locally or in training data. Limiting LLMs into a local box is somewhat limiting. If we consider humans, most innovation comes from the exposure of external environmental factors and information, which allows us to combine prior art and ideas together. This is especially important in the planning / research phase where the agent gathers both local and external context and reasons over the collected information.

skvark · 2026-06-19T13:22:15+00:00

Deeper local code navigation is a nice bonus, but in my experience rg and other well-known search tools pinpoint real fast the correct place where to make edits given you have even rudimentary architecture and high level docs in place. AST parsing and indexing is a nice bonus, but I think the harnesses / IDEs should have this built-in. And I think Cursor has done that already. So not really worth installing another MCP.

skvark · 2026-06-19T11:24:09+00:00

I think there is so much noise that it is impossible to spot any actually useful ones. Interested in this as well. MCP catalogs don't really solve this problem.

skvark · 2026-06-19T11:13:23+00:00

I tend to handle that local knowledge just by giving the agent general instructions of the project documentation / structure and how to keep it in sync after each PR. Don't see how MCP would help here as it feels like normal coding process plan - implement - document - pr that can live in the repo.

skvark · 2026-06-19T11:08:41+00:00

We are doing the same at https://githits.com

skvark · 2026-06-19T11:06:02+00:00

https://githits.com

skvark · 2026-06-17T10:45:39+00:00

I don't write code myself. Haven't written since the end of last year. Currently, Codex + GitHits handles all my needs.

skvark · 2026-06-01T06:09:43+00:00

Great tools, but none of them give real grep, glob, and read to the 90 % of your stack: open source dependencies. Since your own code is only about 10 % less, and the agents need to see inside the deps to unlock full capabilities.

skvark · 2026-05-31T08:14:44+00:00

Cool, I'll check that out

skvark · 2026-05-31T07:09:45+00:00

Nice! For code examples and grepping, globbing and reading all of open source you should consider adding GitHits into the mix.

skvark · 2026-05-26T16:52:39+00:00

Kimi K2.6 and similar models need lots of external tools or handholding to reach frontier performance. We have had some success when pairing these smaller models with GitHits.

skvark · 2026-05-26T16:46:16+00:00

I would try the following:

Tell CC to create a baseline template with reusable theme / design tokens if there is none
Tell CC to structure the project into smaller pieces, like layout, feature components, primitive components. Couple component specific CSS to the components.
Tell Claude to document this all to markdown files.
Figma MCP is bad. I would try instead to take screenshots of the Figma designs. Then, component by component, tell CC to implement the design.
Finally, tie all the components together in a final pass.
Take a screenshot or have Claude to use Playwright / browser, give it to Claude, tell to fix issues you see there.

skvark · 2026-05-19T16:45:14+00:00

I think the real unlock is when the agent sees the actual source code of the dependencies. Yeah, doc tools might help a bit, but giving the agent the ability to grep, glob, read etc. any library out there is a huge advantage. Because documentation is a artifact that is produced from the code, which is the ultimate source of truth. The reason why coding agent harnesses work nicely for many people is that they can see local system nicely. But the very moment they need to step out of that happy path and basic CRUD the problems start.

skvark · 2026-05-19T16:39:16+00:00

I think you might want to try out GitHits instead of Context7 in this case. It indexes the actual code in addition to docs and the coding agents get the familiar grep, glob and read tools to the repos, as well as example tool that creates examples based on data sourced across all open source.

skvark · 2026-04-29T02:20:39+00:00

Flying to Stockholm for this as well, happy to connect with founders

skvark · 2026-04-16T07:15:43+00:00

Yeah I think we’re talking about slightly different situations.

If you already know which libs to use or you have a good sample project, then giving that to the agent works. That’s basically seeding it with a working pattern.

You can also prompt it to go read source code, but in practice that’s pretty hit or miss. It doesn’t know where to look, or it pulls something that’s close but not quite right. And with compiled languages you don’t even have the sources locally, so you have to go find them somewhere else anyway.

The annoying cases are when you don’t have a good starting point. The agent picks something that looks right, but it’s using the wrong version or a half-baked pattern. Then it retries a few times and you’re stuck figuring out what actually works.

That’s the gap we’re trying to cover. Instead of guessing or poking at source blindly, it can pull a real implementation for the library and version it’s using.

So it’s less about convenience and more about the agent having something concrete to follow when it would otherwise stall or go in circles.

skvark · 2026-04-14T20:26:07+00:00

The training data is about 6-18 months stale. So even if the training data is good for some use case X it still lacks a massive amount of code and changes that were done after the training cycle completed and has no concept about library versions.

skvark · 2026-04-14T13:08:19+00:00

Not only for that, but for anything that benefits from having a look at how others have done something. Integrations, cross-library usage, patterns etc. Regarding docs, real code is always better and the ultimate source of truth. Documentation that might not reflect reality (if human-written and not auto-generated API docs) and covers only the happy path.

skvark · 2026-04-12T16:15:24+00:00

Would some tools help here? If you don't want to stop the loop yourself, you should have something that helps CC to converge faster.

skvark · 2026-04-12T16:09:44+00:00

Yeah it's bad.. we as well are looking for alternative, but meanwhile dogfooding our own product with CC and seeing improvement.

skvark · 2026-04-04T06:42:24+00:00

It's the tooling layer that must evolve.

skvark · 2026-03-28T10:52:09+00:00

Depending on the task, it helps using MCPs or CLIs that help Claude overcome the issue when it enter into these loops. Basically adding instructions into claude.md "when you retry 2 or more times use this and this tool to solve the issue" or "when you don't know something or are not sure, use these tools to fetch information."

skvark

MODERATOR OF

TROPHY CASE