logoalt Hacker News

spacedcowboy • today at 11:42 AM • 6 replies • view on HN

I’m slowly coming around to the idea that if it works, I’m good with that. I never used to personally check all my colleagues work, either, I just trusted that they’d done a good job.

That’s not to say I blindly trust an LLM - my project is an autovectorising compiler. I have it write a bazillion tests, and I have real, non-trivial programs that it compiled. I have it run a ‘gate’ before releases that takes literally hours on 5 different architectures. To say this code is tested is … masterful understatement.

I think what helps is a long planning session, going into details, working out corner cases, designing test-cases, you know work and effort. Once that’s done it’s easier to let it work through the night and do a major production feature.

I still review the code, but hand on heart I couldn’t say I’d reviewed everything, sometimes I miss something in a complicated check-in. I try to keep checkins small and contained, but sometimes that’s not easy to manage alongside the “don’t break stuff” rule as well.

So it comes down to: I’ve been working on this for 6 months or so, and so far this has worked out for me. You know, kind of like getting used to a colleague’s idiosyncrasies over a period of time.

I will say that in my experience the code quality is fairly high. Maybe that’s down to the effort put in ahead of time in the planning stages, I don’t know, but I don’t seem to suffer from the ‘slop’ that people complain of. YMMV.


Replies

yulaow • today at 12:01 PM

I am not in META but for what I read on blind, assuming it is true, they are not spending any time in long planning sessions or in getting into details of the implementation plan at all, and they could not anymore considering how many PRs in parallel they are requested to manage

➕ show 1 reply
jimbokun • today at 8:09 PM

Yes, compilers are a good candidate for verification through thorough testing. If a comprehensive test suite passes, reviewing every line of code isn’t so important.

phyzome • today at 8:11 PM

See the first paragraph here: https://alexgaynor.net/2026/sep/07/is-it-correct/

If your definition of "works" includes "doesn't have vulnerabilities", you're going to need to do more than just poke at it and add tests.

➕ show 1 reply
chrisjj • today at 6:57 PM

> I’m slowly coming around to the idea that if it works, I’m good with that.

A.k.a. "The concrete didn't crumble when I hit it with a hammer."

Process quality has been a thing for ages because it is essential.

➕ show 1 reply
sixothree • today at 8:22 PM

Very similar here. For internal projects the test is - if it works, unit and integration tests were created, and it follows our architecture correctly.

dmitrygr • today at 9:31 PM

> never used to personally check all my colleagues work, either,

Jesus F Christ! No wonder most software lately (~decade) has been shit. Have y'all not heard of code review? Or did you think it just for show...you sit on a change for a week and then press "Accept" without reading it?

➕ show 1 reply