Hey, look! I wrote another compiler.
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41841
| Pronouns | she/her |
| Website | https://www.gfxstrand.net/faith/ |
| GitLab | https://gitlab.freedesktop.org/gfxstrand |
| GitHub | https://github.com/gfxstrand |
Hey, look! I wrote another compiler.
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41841
@dneto As an amusing anecdote about this:
About a decade ago, a new guy showed up in Mesa, tasked with fixing all the endianness bugs in our texture code. He was a pretty experienced engineer but new to graphics. Several times he tried to pull a “I’m not sure if this is the correct fix but it fixes more tests than it regresses so it’s probably moving us in the right direction.”
Eventually I had to tell him, “No. This is endianness. It’s a parity problem. The test passes if and only if it hits an even number of bugs. A random walk of fixes and regressions isn’t going to converge. We have to be sure of every fix.”
@dneto Oh, for sure.
And I’ve spent an annoying amount of my career fixing foundational problems in code bases maintained by “I don’t get it, you don’t get it, but it fixes the CTS test so it must be an improvement.” They’re inevitably broken as shit on the inside and fall over the moment you sneeze but, hey, the tests pass, right?
And when I go do that big, scary, invasive fix that touches parts of the code no one else is willing to, I inevitably end up deleting a bunch of lines from our xfails file along the way and a bunch of long-standing bugs light up with, “This suddenly works now. What changed. Oh… Faith’s MR.” And occasionally a junior engineer will complain that I sniped them and fixed the bug they were working on and I do feel a little bad about that.
But so much of the time it could hear and should have been fixed long ago if the engineer who found the first bug had actually root causes and fixed it instead of saying, “it doesn’t seem to work in this case” and adding in a hack. Eventually, the pile of hacks falls over.
But this is the whole MO of chatbot coding. Hack until the tests pass.
Like I said in the previous post: Every. Bad. Behavior. Amplified and at the speed of AI.
@dneto It wasn’t that, actually, though is a good lol. I’ve been seeing a lot of different things different places.
And everything I see is ultimately stuff I’ve seen before. It’s all the same players. It’s all the same social problems. It’s just that every bad emergent behavior that we’ve ever seen come out of the software industry is happening again, only amplified.
The new tech enthusiasts have a new toy but this time it really is going to change everything. The overconfident assholes are still overconfident, still incompetent, but are somehow bigger assholes, now powered by AI. Managers who’ve always wanted free (or at least predictable output per dollar) productivity think they’ve finally got it. Abusers with power now threaten people with AI replacement if they don’t fall in line. Every oppressive manager or CEO who thinks their team isn’t working hard enough, throws a token budget at them and expects 5x the work and when they can’t deliver (duh) blames it on the engineers for not using enough AI because clearly their expectations were reasonable. (They never were.)
And anyone (manager or engineer) who doesn’t want to actually collabora throws a chatbot at the other person. Don’t want to do code review? Claude can do it. Don’t want to deal with Jim’s review feedback? Just feed it into Claude. Don’t want to help your reports with their year-end review? Just prompt ChatGPT. No one reads that bullshit anyway.
I could go on.
And yes, there is potential for good here. There are absolutely BS reviewers you don’t want to deal with and managers who want an 11 paragraph email instead of the three bullet points of actual information. But in practice, so many of the people I see using it or the ways in which it’s used are the bad actors. The person who cares will human review your AI generated PR. The person who views other contributors as a bother will just tag Claude for review and waist your time going round and round with a chatbot for a while before they’ll actually spend time reviewing.
@dneto When we cheapen the implementation by saying, “an AI can do it,” we also cheapen the feedback the implementation gives us and that models we get suffer for it.
Managers love it because they think they finally found the mythical man month. They finally found a direct way to turn dollars into code.
Senior engineers who don’t write much code anymore love it, too, either because they get a power kick out of ordering the AI around or because they get that rush of writing code again, packed into their limited schedules.
But is it actually good? I have yet to see it.
@dneto Like, looking at spec work as an example… We write the spec, yes, and people go implement it. But then we spend interminable time revising and adjusting the spec because, at the end of the day, we’re defining the behavior of concrete implementations which behave a way, whether we want them to or not.
And yes, as spec (model) authors, we can carefully push those implementations in directions we think will be positive. But doing so requires a constant feedback loop in which the people modeling listen to feedback from the various attempts at implementation. If you don’t do this and just spec into the wind, you end up with OpenCL 2.2.