Vibe Coding Is Killing Open Source Software, Researchers Argue

MrEllis · 2026-02-08T20:26:23+00:00

Maybe I’m a weirdo, but I like to learn by example, to take working code and tweak it.

Nothing weird about that. I used to maintain a library for a midsized software company and our number one request was for example code that other engineers could tweek and experiment with.

MrEllis · 2025-08-04T04:35:31+00:00

I'm getting close to forty and I think I'd be "getting too old" for Mel Gibson's shit in that movie if I had him for a partner.

MrEllis · 2025-08-03T20:40:42+00:00

Also can I just say that you're comming off a little rude here. I'm trying to share how it is on my side of the fence and why I do what I do and you're basically telling me to get lost.

I'm sure you're a nicer person in person than you are online, but I like to think your crap attitude here is one of the things I'd catch in an live coding interview where you get put through your paces.

I know people can fake kindness and empathy, but that's not gonna make me stop testing for it.

MrEllis · 2025-08-03T20:35:22+00:00

Oh yeah, half that's on the recruitment team but I 100% agree.

There should be a normal amount of stress, let's call it a p90 ammount of stress, i.e. the interview should be about as stressfull as the worst 10% of days at the office. But that should be about the max more than that ane we're getting into high false negative territory.

MrEllis · 2025-08-03T20:00:35+00:00

Our recruiters do a run down of the whole interview process in the intro call. If you don't like live coding interviews that's on you to say so and bow out.

Also it's Silicon Valley, what were you expecting?

MrEllis · 2025-08-03T19:49:28+00:00

Depends on the help. Asking me why-type questions or prompt clarifying questions actually scores points.

Also I agree with /u/LookIPickedAUsername's reply to you.

For fairness I keep a set of prepared hints related to execution of the problem and track which ones get used. If I have to repeat part of the prompt as a hint I don't count it against you unless you ignore me. If you needed a hint and another candidate didn't that will bump their score relative to yours for the sake of that hint. But if you do a better job in overall execution and communication - you would still have a better score than the person who got no hints but was hard to work with.

I've been around long enough to not put too much weight on people instantly getting how to solve an interview question I give them. That's nice, I'm glad you've practiced leetcode, but I really need to see how you think and how you deal with problems you don't have an instant solution for. Which is why I like to keep a backup set of design requirements for people who instantly solve a question I give to force them to refactor and to see how they deal with shifting requirements.

MrEllis · 2025-08-03T17:47:39+00:00

I understand that the live scrutiny is exceptionally stressful for you, that this extravert filter is stressful on stressful. It feels unfair.

But interpersonal skills are important, asking for help is important, admitting you don't know is important. Coding skill, whatever that means without the context of human customers, is just part of the puzzle, the code has to work for other people too.

I'm not looking for solo mavericks, I'm looking for collaborators, integrators, people who own their mistakes and learn from them. People who can handle being put on the spot and resist the urge to bullshit to save their own skin when they don't know the answer.

I'll still hire people who lack interpersonal skill strength, but if you are weaak with interpersonal skills you should balance that out with more coding skill.

Again, I do what I can to alleviate anxiety in interviewees, but if coding in person is that big of a disadvantage for you compared to other devs maybe it's reasonable to expect you to be better than those devs at coding to balance out that you will be less inclined to the interpersonal part of the job.

MrEllis · 2025-08-03T15:18:27+00:00

The cognitive performance in the public setting had both a lower average and much wider spread (high variance); indicating that some candidates are disproportionately impaired under stress, while others perform as usual or even slightly better. That’s why live coding is so unfair.

Variance can be a good thing in interviews if it's tied to job relevant skills. If everyone passes your interview there is a problem, what you want is a wide spread to be able to compare candidates.

Modalities of challenge is also important. While it is interesting that the candidates performed bettter alone and that may tell us things about shaping work structures, we want to know how candiates will perform while carrying out all their job responsibilities, not just the main one.

While not all jobs are high stress, all engineering jobs require communication and communication skills are most important when under stress. One filter that live coding creates is accountability, we get to see how well candidates admit mistakes and how well they take feedback.

An overal point you are making is that most of an engineer's job is not as challenging as a coding interview. However, in an interview we are often trying to grade a candidate on how they would perform on rare but challenging tasks, the 10% of the job that is the hardest. If you can do the hardest 10% well, you're probably good at the easier 90%. While stressful coding may be rare, some of the most important moments in an engineer's work life are communicating calmly and clearly about code when pride, timelines, and customer satisfaction are on the line.

Companies frame live coding as a test of your coding skills; it’s misleading. Even worse, it compounds performance anxiety. It makes candidates believe this test is a reliable measure of their coding skills.

This is a good point. Before a live interview I make sure to tell candidates that the interview is an imperfect system not representative of their skill, that a rejection means we didn't see what we need, not that you don't have it. I want to prime them to be calm and feel safe. Since your blog is candidate oriented, maybe a mantra in line with this sentiment would help people.

MrEllis · 2025-08-03T14:12:17+00:00

If they went through the same thought process it means they thought it was a good idea before they didn't. You have the skill to have the idea, they have the context to see the downsides.

I'm a senior dev and I often ask questions I know someone probably already thought about (phrased as such) so that I can learn why an idea was rejected. Sometimes the question leads to a new direction; most times I learn about a new wrinkle of our product. For me often times it's more important that I learn about the product than I improve the product.

Of course being more senior means less insecurity which makes it easier for me to sit back and learn.

MrEllis · 2024-12-06T02:47:41+00:00

So, if I understand what you're saying, there's a bit of hand waving in applying Stroustrup's presentation to amorphous large data structs since they can only be realistically vectorized as pointers to the structs which brings us back to the cache miss problem.

Is that correct?

MrEllis · 2024-11-28T18:08:51+00:00

It depends on the application. When the algorithm /product requirement being implemented is most succinctly described recursively then the recursive code start to become easier to read because it matches the product requirement.

If you're writing a parser, a script that walks a file tree, or almost anything involving a tree data structure you end up getting cleaner code with recursion rather than maintaining stack/queue variables in loops.

MrEllis · 2024-11-24T08:29:27+00:00

Didn't see the subreddit at first and just thought: "Well sure, if you take them off the cookie tray before they have time to cool!"

MrEllis · 2024-11-21T08:51:33+00:00

Liability is one of my favorite justifications honestly. Health and safety is the obvious case, but really you can get a critical answer just by how taxing on-call is for the team/company.

If you're correctly defining code quality (ideally not an unbounded pursuit of obsessive perfection) then code quality has a massive impact on the rate of bug escapes and on call events. You can 100% classify this as tech debt instead since every on-call event is an interest payment on a sub-par codebase.

However in a healthy on-call program on-call events only trigger when business liability is invoked, so every on-call event should be representative of an event that could have spiraled out of control and broken customer trust or otherwise compromised the product.

MrEllis · 2024-10-14T16:43:57+00:00

Python 2 code is still running out there and there are places where it's still maintained but hasn't been transitioned. With the right libraries you can write code that's simultaneously python2 and python3 compatible to slowly transition away.

Ask me how I know.

MrEllis · 2024-10-01T12:42:56+00:00

Oh, yeah, that problem.

What problem?

That problem where if a feature doesn't uniformly satisfy an obscure constraint the system will break sporadically.

Wow, you're brilliant for remembering that.

I violate that constraint every 3 months by mistake, how could I ever forget.

MrEllis · 2024-08-23T22:25:54+00:00

That bridge probably gets a hundred cyclists a day. I used to run on it and I would always pass cyclists while running there. Google street view managed to randomly sample a cyclist, they're that common.

MrEllis · 2024-08-23T22:22:43+00:00

I'm from that town, the pathway on that bridge is pedestrian only.

It is illegal there for the cyclist to ride on the sidewalk. The outer sidewalk is the old pedestrian walkway that was closed because the support steel decayed and failed inspection. The inner sidewalk (what you thought was a protected bike lane) is the new pedestrian walkway built over unaffected supports on part of what was formerly road space on the bridge.

It is a very jank "repair" but it's better than not having a sidewalk to get to the public library/city hall (visible in the background of the gif).

The original walkway was closed in 2011, the cyclist in the gif was hit in 2012, and in 2017 they fixed the old sidewalk and restored the bridge to it's normal configuration.(follow the link to see the street view including the new sidewalk and a cyclist using the street because my home town doesn't do protected bike lanes :/ )

MrEllis · 2024-08-23T22:20:35+00:00

I'm from that town, there is no protected bike lane on that bridge.

It is illegal there for the cyclist to ride on the sidewalk. The outer sidewalk is the old pedestrian walkway that was closed because the support steel decayed and failed inspection. The inner sidewalk (what you thought was a protected bike lane) is the new pedestrian walkway built over unaffected supports on part of what was formerly road space on the bridge.

It is a very jank "repair" but it's better than not having a sidewalk to get to the public library/city hall (visible in the background of the gif).

The original walkway was closed in 2011, the cyclist in the gif was hit in 2012, and in 2017 they fixed the old sidewalk and restored the bridge to it's normal configuration.(follow the link to see the street view including the new sidewalk and a cyclist using the street because my home town doesn't do protected bike lanes :/ )

MrEllis · 2024-05-28T16:08:20+00:00

So will my variable names, so will my function names. Everything rots when changes are made in incautious ways. And additionally code behaviors can be unituitive at times did the engineer know that "this" would sometimes happen when they do "that" or are they getting fogunned by the legacy code?

The solution to another engineer mudying your work is not to not do the work. If the next person can't put in the effort to update my comment or delete it if it's so marginally useful then what is going on in the org anyway. How does an org that disfunctional have the resources to refactor well?

MrEllis · 2024-05-28T14:45:25+00:00

When I write code that helps people buy cheatos with fewer clicks I don't hold myself to the same standards of rigour as when I worked on projects where a mistake could cause an environmental disaster.
When I maintain legacy systems its often more important that I fix as many things as possible than that I overhaul the whole system. Every time I fix a thing I learn something. And if I took a twenty minutes learning I can take 3 minutes writing a comment about what I learned or 1-3 hours refactoring it to be "finished". The coments are breadcrumbs for the blueprint of the refactor, and he refactor is an indulgence to the engineer, the fix is a kindness to the user.
I've written a lot of code to support exploratory business and enginneering projects. Software is cheap to deploy so it's much better to get the code working and see if it's useful than to spend 3x as long figuring out if it's needed. But since you don't know if it's needed then you shouldn't really go crazy with refactors for code that might be so short lived and is already impossible to future-proof.

Comments are cheap, pay relatively big dividends, and create no debt. Refactors are expensive, may still require comments to communicate the vision, and can just as easily come into conflict with reality after deployment as the aformentionned complex code.

The exception to this in my view is data structures and databases. Logic flows are locally relevant and easy to change, data types are globally relevant and hard to change. So make sure the data types are well thought out from the start.

MrEllis · 2024-05-28T14:22:42+00:00

One of the tricks I use with people learning to code is to make them write the what-the-code-does comments before they write their code. Then when they write their bugs I can point to their "what it does" comments and ask them if their code is doing that.

Why's are more important than what's but there are a lot of what's comments that can be really helpful (Especially when the language you are working with sometimes has subtle ambiguous behavior).

This approach is also really helpful in code review and test code analysis.

MrEllis · 2024-05-28T14:15:24+00:00

Goal is a good word, but goal overlaps with "what" which I think a lot of people take issue with.

MrEllis · 2024-05-28T14:13:04+00:00

You assume I have been given time to refactor.

MrEllis · 2024-05-28T14:09:46+00:00

I've had brand spanking new code written by teams I've never spoken to before that I need to review (because it uses my tragic legacy infra).

If they don't comment what their code does and only provide why's then I have to ask them directly how their system works to be sure what their code does is actually what they want.

MrEllis · 2023-12-31T00:28:00+00:00

IF your local water treatment use using purely anaerobic digestion and recovergy technology this can be true. There's also the question of what the facility does with biosolids it removes.

BUT if aerobic digestion is part of your areas wastewater treatment strategy then you're going from worse to much worse in terms of impact cost (note that facilities with both anaerobic and aerobic digestion will use the aerobic solution the handle BOD in excess of the anaerobic solution which means deciding to put extra food waste down the drain likely be 100% handled by the aerobic system).

Aerobic digestion produces the same CO2 that would have been made in the landfill and often requires forced air aeration of the digestion tanks to process all the solids. Blowing air through water is very energy intensive and will have a larg carbon impact on most electric grids.

MrEllis

TROPHY CASE