u/schneems

This is at -1 ATM, and no one is responding. If you dislike something. Please use your human fingers, type it into a comment, and let me know why.

This is the policy https://forge.rust-lang.org/policies/llm-usage.html.

What I'm suggesting using agents for here is well within the policy (private use), and the thing I'm suggesting (researching/learning from prior PRs) is a thing I've advocated for through https://codetriage.com/ for many years manually. Doing it by hand is better, and you'll learn more. This is a contribution I made to clippy with 0% AI https://youtu.be/TJ2cdCTyDfY.

Thanks. I missed that bit. Ruby Central (I'm on the OSS committee there) also has an "in-kind" engineering program, which this seems similar to. What I've suggested here is more like a "step zero" before getting to that point.

I think that all companies should have every engineer be fluent and engaged with upstream open source. Some will prove to be better at that engagement than others, and they would be good candidates for something like the engineer-in-residence program. (which, yes, talking more about it would be welcome!)

I think the largest companies should aim for 1-2% (or more) of engineer spend on OSS. Through a combination of encouraging "work hours" work, engineer-in-residence (or "in kind" engineering), and direct financial contributions. The largest companies should balance that contribution knowing that throwing a TON of well-written issues and patches at projects that have few maintainers won't help much, and might even slow things down. And there are admin fees and base costs to running organizations (like Rust Foundation) that are important to help with too. Sort of like a three-legged stool.

So I'm not trying to say "don't donate, use your time instead." I'm more trying to say: the best companies, and best teams contribute upstream. If you're not, or don't think you can: donating is easier. Likewise, developers putting issues and PRs on their company kanban boards raises awareness and visibility of the costs of maintenance and might help start the conversation for a future donation or in-residence engineering position .

100%. If you must use an agent. Have it do research and review your work. Like:

Research 10 closed issues that were closed because of a successful PR. 10 that were closed without a successful code change. Summarize elements of a successful issue and things to avoid in an unsuccessful issue. Read the comments and find ones made by members or contributors to the project. Summarize any requests or questions they made.

Then read the report. Some stuff is table stakes like: describe expected behavior and what actually happened. Include errors or outputs. Include a simple reproduction of possible in the form of code (not described steps which can be missing hidden context).

Write the issue and based on the report can have a fresh agent review your work. Don't just let it make changes an explicit "refuse to make explicit changes, refuse to rewrite my words only make suggestions" so it's less likely to do the easy thing and turn off your brain and copy its output.

Before hitting submit: read the whole thing out loud start to finish. 

Also note that rust and clippy have strong LLM policies. Read them, follow them. Pay attention to the definition of "written by an agent" as it's kind of hiding at the bottom and means rewriting an agents work does not qualify as "written by you".

A thing I don't see mentioned: encourage employees to put OSS on the kanban board.

If you hit a bug at work: take the time to write a REALLY good issue with a reproduction. Do it at work. Track it and get recognized for that work. Next level: provided community reviews and triage at work. Next level: fix bugs, send PRs,  and participate with zulip and discussions at work. Put it on the kanban board.

Direct funding through sponsors and funds is good. Doing OSS work on company time and getting recognized for it is good too.

Read more. Don’t worry about writing as much  https://www.codetriage.com/?language=Rust

Rust and clippy have policies against LLM contributions without prior auth. But I caution against starting there. A PR is free like a puppy. The maintainers have to spend a lot of time for every one and then own the maintenance costs on it forever. It would be better to start with a smaller project that has more need of help  https://www.codetriage.com/university/picking_a_repo.

And since it's relevant. I just did a live video contribution to clippy without using LLMs. Video:  https://youtu.be/TJ2cdCTyDfY.

On Heroku changelog:

Default Ruby version for new apps is now 3.4.12

Ruby version 4.0.9 is now available

Ruby version 3.4.12 is now available

Ruby version 3.3.13 is now available

What is up with the bathrooms in this location?

Well, if you go back to 1928 https://en.wikipedia.org/wiki/1928_Austin_city_plan there was intentional and systemic efforts to segregate Austin and force non-whites to the east side and then to give them lower quality services.

Even though that's not been policy for a LONG time, we still feel the impacts of those decisions. When there's elementary schools closing, they close on the east. When there are transition housing built it's built on the east. Parks on the west(ish) side like Pease get amazing upgrades and have beautiful bathrooms. The best we can say about parks on the east is that they exist.

Not to mention why that park even exists in the first place. It's because there used to be a trash incinerator power plant there, and the parks were built as a buffer for the neighbors as a half-hearted peace offering.

Endorsed. I would also say that LLMs (like humans) are self reinforcing. If you let them be a little sloppy. They will take that as an excuse of “this is how things are done” and be more sloppy.

You HAVE to find a place to inject quality and improvement into the process. The old way was code review and PR time. If that’s not the “new” way. It’s not good enough to blow it up with no replacement.

As a reminder there is a stickied recurring job post on this sub. If your company is looking, please cross post your listing there  https://www.reddit.com/r/ruby/comments/1wo8f6o/work_it_wednesday_who_is_hiring_who_is_looking/

https://en.wikipedia.org/wiki/Austin_City_Limits_Music_Festival

Apparently, the answer is “yes it is open” but I guess the downvote button is easier than replying  https://www.reddit.com/r/Austin/comments/1wrs008/barton_springs_and_acl_weekends/

It’s ACL right now is Barton springs open?

An attempt at functional programming.

To explain: When you have your program represented by inputs and outputs only, then your logic is isolated, and easi(er) to test. Ruby, being object oriented, it's really easy to add accessors and extra features that mutate the data in ways that might not be very clear at first glance. With a service object you get a very clear input point, and a very clear output point. It's not exactly purely "functional" but having written a bunch of Rust, it's the closest I can get to isolating my code from side effects of future code changes as the language provides.

In very large files in Ruby you can see weird interactions that are hard to predict/trace. It's not always clear what's a helper method versus an attr reader versus even a local variable sometimes. By limiting the scope of what goes in an individual class (for a service object) you also limit your complexity. It forces you to pass information in and out of them, more, but that's a good forcing function.

It's not the only pattern, but it's a pretty good one

Ask yourself this, do you trust yourself and other humans who only have 2 eyes that can only see in the visible light spectrum with a limited ~160 degree POV to operate a vehicle safely?

Humans don't just drive with one sense. They also use their hearing to listen for horns or sirens. They use their sense of proprioception to feel how the car is moving through space. They use touch and vibration from the steering wheel, and seat. Possibly even sense of smell to detect burning rubber which might hint someone's brakes locked up recently.

If I have to choose between two drivers, one has full access to every avaialable sens(or) and one that has only one sense (sight). Then I think they're at a disadvantage. Additional software cannot make up for lack of sense/input.

You're also equating the senses of a human with that of a computer/robot. Which are not the same. The processing power of the brain is orders of magnitude upon orders of magnitude (upon orders of magnitude) higher than the biggest, fastest, supercomputer. The human eye is similar degrees better than the best resolution video. When I say "hardware" I don't just mean "sensor hardware" I also mean the whole package including processing power (CPUs) and camera quality. You can make more efficient software that runs better/faster on limited hardware, but at some point you hit a wall.

The competition, on the same CPU/processors, can devote more resources to the actual act of driving than doing the conversion from 2x2D stereo images to 3D guesses before it can start to reason about where its' going.

Because having all the fancy hardware in the world means jackshit if the brains of a toddler was actually behind the operation.

Sure. And thats why I shared my experience that I've seen a dead tesla in the street, but never a dead waymo. "Brought to you by the guy who did 'Doge' for the government" and "brains of a toddler" might actually be a good comparison.

Correct. I'm easy to google. Also fameously cannot spell. What's your masters degree in and how does it relate to the conversation?

Or excon

Thanks. That makes sense. It is a bit jarring.

I guess "no code is better than 'no code'" and "code I don't look at" is the next best thing? Or "love is blind" or something? IDK, weird/strange times.

Seems like Ken Paxton isn’t feeling super comfortable with his current poll numbers.

We should have empathy for the observer.

Yes. I love this.

A LLM explainer comment at the top of every method is not the path we should be going down in this language, regardless of the tools we are leveraging.

I couldn't agree more. I find it actively harmful in many/most cases. I DO believe in good documentation written with intent and (totally stealing your phrase) empathy for the observer. Most LLM comments either state the obvious, focus on what instead of why or leak context in some confusing way (talk about things not in the codebase).

I think docs is one area where most devs had literally zero skill points so they're unable to call BS on poorly written ones. But now the best of us have learned how to write good docs and are pushing back.

Just in case anyone forgot.

What were you emphasizing/implying? Compare and contrast "Optimize for programmer happiness" with the keynote maybe?

[doctrine] We need diversity of thought and people

In that order 😬

Thanks Robby!

I think David(HH)'s "I don't even look at the code" is a dangerous statement and mantra as people will take it literally.

I don't think "looking at the code" is always how you get quality though. For example: when I review PRs (from the before times) sometimes I don't read the literal code, some times I read the tests to understand "what can it do" and I might suggest additional tests or object to some behavior shown in a test. Or I boot up a review app and click through the flow etc.

That's why I think "I don't even look at the code" without a "here's how I ensure quality, with XYZ" is dangerous and really just not a useful phrase. If he doesn't do that, what does he do? Clearly there's iteration, what parts are automated and what parts arent? That might actually be interesting and useful instead of "white pill losers read code" (paraphrasing).

At the very least, you should understand, review, and shape the outputted code to the best of your ability.

I have a very high standard at work. I also maintain a very high standard in my open source. Everything I produce is from me and I want to be able to stand behind it. I want to use tools to increase my rigor. Which...these tools do not always make easy.

A thing I'm struggling with is: Optimizing for humans or for machines. Humans make classes of problems machines rarely to (like typos, using "/tmp" when they meant "tmp" without the slash). So I spend a lot of time writing code that defends against human misuse and misunderstanding. Machines don't always do this, and sometimes they make different weird mistakes that are hard to empathize with, therefore they're hard to correct.

Humans are sloppy, and lazy, and do a thing that is "good enough" all the time, but in a different sloppy/lazy way than machines. The balance of "good" and "maintainable" is where we need to figure where to draw the line.

The dangerous side of the fence is to just let LLM completely replace you as a maintainer

Matz is an interesting study. He already replaced himself as a maintainer for Ruby. He says he's always been a vibe coder (he has Ruby core contributors that do most of the work and he just weights in on high level issues and vibes). I think there will be some classes of tools where "vibe code loop maintainer" is actually perfectly valid and are good enough quality. For him "replacing me as the maintainer" is probably a good outcome. But such a feat is really hard, it's difficult to bring in a team to train them to replace you and continue to do a good job. If he can do that, he brings skills to the process that will continue to add value to this process or another.

But I also think there will always be a percentage of 100% hand written code, and a hybrid synthesis with everything inbetween. I think if you're after the actual best outcomes or we will land on human assisted hybrid workflows. Even before LLMs we argued constantly about tradeoffs and what was good enough. It's the same battlefields, even if the arsenal (TDD, docs, code reviews, LLMs, etc) have evolved.

The software still matters

Right. Sure. I never said it didn't. But in this case hardware is the limiting factor. Which...both my videos go out of the way to explain.

I have a masters in computer science from georgia tech with a specialization in Interactive/Artificial Intelligence. You can correct for bad/noisy sensors up to a point, but it's a game of signal versus noise. The hardware dictates what can be sensed. No radar, no lidar, means significantly worse distance measurements (lower signal, higher noise). The visual-only system requires more processing power to do the same work, and is subject to higher rates of failure.

For a metaphore: the waymos are like a construction worker with a tape measure telling you how long of a board to cut, the teslas are holding up their thumb, squinting a bit, then giving you a number. It's possible both mesurements can be useful. I trust one to be more accurate.

I have seen videos where this test was replicated in a cybertruck using full-self driving and it did stop before the wall.

1) Great, have a link?

2) The Rober videos doesn't prove that that the tesla isn't capable of seeing a wall. It proves that there are conditions where it will not. Likewise a "FSD" (which is a joke of a term) car behaving as you describe proves it can stop, not that it will always (or even mostly) stop. The "smashing into a road-runner-wall" isn't a real problem real cars have to face. It's to illustrate the limitations of the sensors, which it does. And until the sensors i.e. the hardware change. It has the same limitation when compared to other (actuallly, literally) fully self driving cars.

Which is to say: I don't clutch my pearls and bring my kids in from play when I see one of these things (which I do, regularly). I took a ride in a Tesla robotaxi the other day that someone else in my group booked and paid for. It was fine. I didn't even die.

My issue is: There will be scenarios where being slightly faster to react, or having slightly better data would prevent injury and harm. If I have the choice of where to vote with my dollars, I choose to over spend on safety and quality and then figure out how to bring down costs later. I choose good sensors. I choose companies who value these things. Tesla is taking the opposite approach. Cut costs agressively and hope they can undercut the market. I hope you're right and the strategy works well. I trust that the people in the cars will likely be fine in the event of a crash. I just prefer to be walking or driving around a waymo instead of one of these things.

Also: Two weeks ago a robotaxi was dead near an intersection by cesar chavez and blocking traffic when we drove by. I've never seen that with a competitor which have significantly more cars. I just don't think the quality and care is there. Even if the software solution is good enough, I need the product to be better, I need it to be outstanding.

He talked about this in his RubyConf keynote (which notably, included Ruby) https://www.youtube.com/watch?v=FOg0bL3auFk. Its a good talk IMO.

I'm on the fence here. I think that there's no "one right way to develop" before or after LLMs. I think it's good he's not trying to pretend it is him. He also takes ownership of the final outcome.

If he feels whatever he is doing is good and correct and wants to share learnings from it (specific skills, workflow, tools etc.) that would be nice. If it degenerates into something unmanagable learnings from that would also be good/nice.

AI is best on greenfield projects (prototypes etc.). Which spinel is. The looming question (as always) for coders is "how do we increase or maintain quality" while increasing or maintaining quantity?

different software

The core part of the video is the HARDWARE, which the video explicitly talks about. The longer video goes into detail (Post title "Tesla kills small child... over and over again." https://www.reddit.com/r/videos/comments/1jce3f9/tesla_kills_small_child_over_and_over_again/).

This is a problem that can not be solved with software (today). This approach is unsafe and pure hubris.

Technology Connections has a great video on a much more mundane system they've outsourced to software/cameras (rain detection) that explains why it's basically a cost cutting measure, and one that's deeply ineffective https://www.youtube.com/watch?v=TLm7Q92xMjQ. If it's not good enough to keep the rain off my windshield: It's not good enough to keep my kids alive.

Waymo and others have very visible lidar and randar sensors and I trust them driving on the streets where my kids walk than a Tesla.