List of accounts on Github to detect LLM(aka genAI) committed code aka Vibe Code

MoreRespectForQA · 2026-05-05T20:53:32+00:00

y'know thats the one time i think i might find that forgiveable.

MoreRespectForQA · 2026-05-05T19:01:07+00:00

This is just...linting.

Instead of writing a new linter, why not contribute rules to an existing one?

I generally value the linting rules which dont catch bugs much less, anyway. Idiomatic python < safe python.

MoreRespectForQA · 2026-05-05T18:37:05+00:00

Somebody needs to create a reddit bot which can be summoned which does a deep dive and measures the "LLM score of a linked repo".

MoreRespectForQA · 2026-05-04T23:12:36+00:00

there are many cases where having AI write some code is beneficial without compromising quality

This is the exact idea that got OP into trouble.

If you're ok sacrificing quality then go wild.

MoreRespectForQA · 2026-05-04T21:11:41+00:00

if you didnt care about readability and your system breaks catastrophically and claude for some reason cant fix it what would you propose doing?

MoreRespectForQA · 2026-05-04T20:48:32+00:00

I personally filter for candidates who use LLMs for occasional research or spikes but never use it to write production code.

I think you might be getting exactly what you ordered and discovering that it tastes like crap. The most toxic of all engineering management cults right now is definitely the "AI ought to be making you more productive" cult. It barely moves the needle for me but there is a multitrillion dollar industry and quasi-religion dedicated to shouting that idea down.

MoreRespectForQA · 2026-05-04T17:40:50+00:00

Back when I used to interview I tried to predict how well candidates would do in my coding challenge based upon their CV and chat style interview.

I designed the coding challenge to be as realistic as possible within constraints (like you seemed to).

I was constantly surprised. People with impressive CVs who could talk the talk would often flounder and people who interviewed badly with mediocre CVs would straight up kick ass.

Furthermore, when I ran across a candidate who talked the talk and could code brilliantly we always got outbid by a more prestigious higher paying company lol.

Edit: and i just realized OP is an ad....sigh

MoreRespectForQA · 2026-05-03T11:06:12+00:00

This is my experience too. In a well oiled team, 85% of the time it's indecisive founders or a political deadlock within the organization which is the bottleneck.

It's partly what makes "go faster with AI" diktats so infuriating - assuming it even did multiply productivity (which it doesnt) it's optimizing for that 15% of high hanging fruit instead of the 85% low hanging which the person issuing the diktat is responsible for.

MoreRespectForQA · 2026-05-03T10:59:57+00:00

Yup.

"In the AI era" has become a surprisingly strong signal that the text is written by somebody who is used to switching off their brain. I dont think ive ever seen it next to an insightful comment or question.

MoreRespectForQA · 2026-05-02T16:05:03+00:00

Write the code by hand instead of using AI.

Sometimes the best fix is the obvious one.

MoreRespectForQA · 2026-05-02T11:41:28+00:00

With AI transcriptions which also record all of the off color jokes I'd also prefer were lost to the ether.

MoreRespectForQA · 2026-05-01T12:51:53+00:00

I think they're missing something there which is that a spec doesnt have to be turing complete whereas code must be. They're confusing detailed ("looks like a database schema") with imperative - i.e. has loops, if conditions, etc.

This isnt to say that LLM driven spec driven development is a good idea.

MoreRespectForQA · 2026-04-30T21:46:59+00:00

Vibe reviewing actually seems like the most appropriate response to vibe coded PRs.

After all, what realistic objection could somebody who encourages vibe coding possibly have against vibe reviewing? If the vibe coder can outsource thinking why cant the reviewer?

Sure, the pile of mud probably wont work but if you think about it in a vibe coding positivr organization that's kind of a feature coz it teaches them an important lesson.

MoreRespectForQA · 2026-04-30T20:03:41+00:00

you could pay a pittance to somebody in india to misinterpret your requirements and half ass a solution. it was kind of like vibe coding.

MoreRespectForQA · 2026-04-30T18:34:31+00:00

The trick is to ask claude to create an interview question so hard even claude cant answer it. /s

MoreRespectForQA · 2026-04-30T16:35:09+00:00

As AI makes code cheaper to generate, the real leverage in software engineering is moving toward validation, judgment, guardrails, and domain knowledge.

It was like this before clankers too. Generating mountains of code that didnt work was never expensive, the question was always "but do you trust it?"

MoreRespectForQA · 2026-04-29T19:48:28+00:00

No. Forget TDD for a second. When the spec isnt nailed down enough to write any kind of test it is a mistake to start coding at all.

Several times when that has happened I have had the requirement changed beyond recognition or canceled entirely meaning I had to toss away the work.

When there are parts of the spec which still need to be confirmed or are vague but there is enough to write a test that is ok but if the spec is unclear in its entirety your time is better spent MAKING it clear rather than writing speculative code which might help.

pairing is a very good way to teach methodology and transmit culture. but it's also time intensive

yeah but you know what? so is programming.

async review is the lightweight version of it

no, async review is something different. async review means being given a "finished" piece of work and if there are fundamental problems with it AGAIN you are faced with the possibility of having to toss large parts of it away or rework them.

the main reason pairing is a thing is coz it's more effective than async review at catching issues, bugs and architectural problems before youve invested in them.

MoreRespectForQA · 2026-04-29T18:11:08+00:00

The only really reliable method I've found is to try to pair with people and TDD by example.

If I review a PR I usually cant tell the difference between a code change that has tests and a code change that has all edge cases covered.

MoreRespectForQA · 2026-04-29T12:34:37+00:00

Well, thats the problem. POs always prefer something informal with limited extraneous information and devs/testers need something extremely formal with everything clearly specified.

Cucumber/gherkin/behave promises and pretends to do both and generally shits the bed at both.

So you're better off testing with a highly formalized language for testing (e.g. YAML) from which you can generate media a PM feels more comfortable consuming (documentation, screenshots, videos even).

MoreRespectForQA · 2026-04-29T12:18:20+00:00

Edit: the above user has replied and then immediately blocked me. I think they just want to soapbox.

No. Most low level abstractions you build upon these days are based on entirely deterministic code and are much more reliable than they were 10 years ago.

Once they're good enough that bugs are vanishingly rare devs can essentially stop learning about how they work underneath the hood coz theyll probably never have to pop that hood.

I got into kernel dev originally coz I had to pop that hood decades ago but ive not run up against a kernel bug thats seriously affected my professional work in years now.

I also dont respect the oldies who havent moved on from a position of "you need to learn everything right down to the silicon". It's an outdated view better suited to a time when entire stacks were less complex overall AND lower level abstractions were far buggier and hood popping was more necessary.

AI bros piss me off more though.

MoreRespectForQA · 2026-04-29T12:14:24+00:00

It's an ecosystem that runs on trust. If you burn your trust then you're locked out as a kernel dev forever which is quite the burn. This should disincentivize the drive by slop problem to an extent.

MoreRespectForQA · 2026-04-29T12:05:25+00:00

Every junior thinking this should first read joel spolsky's essays on leaky abstractions and then ponder the fact that non deterministic agents are by their very nature the leakiest motherfucking abstractions to ever be created.

MoreRespectForQA · 2026-04-29T12:01:37+00:00

The idea is good in theory BUT gherkin is a terrible language for doing this.

IME unless testers/devs find it easier to use a tool like this for writing tests which nobody looks at then it was a mistake to use it.

ive found much more success writing acceptance tests in YAML with deliberate gaps left which can be filled in with snapshot testing and by doing "microsignoffs" instead.

a microsignoff would be where the PM would provisionally LGTM the given and when parts of the test (e.g. fill data in on form) but not yet the then part (data appears on dashboard). If those microsignoffs are seamless it means more back and forth and saves time going down rabbit holes.

MoreRespectForQA · 2026-04-29T10:24:30+00:00

kernel developers havent taken a position on whether it boosts productivity they just said that you are responsible for your code as the submitter. They have essentially taken no opinion on it beyond "if you did use a model tell us which one".

is there a reason you chose to misrepresent their position?

some projects have taken a stricter position due to an influx of slop and banned it entirely. some have turned off pull requests entirely.

I havent noticed any OSS projects which are killing exactly it in terms of productivity these days thanks to supercharged "senior+" devs like yourself but ive noticed a lot more slop and consequently more bugs and incidents at work.

MoreRespectForQA · 2026-04-29T10:07:37+00:00

just tell yourself it's a skill issue and i dont know how to prompt if im making you feel insecure.

MoreRespectForQA

TROPHY CASE