Your job is to deliver code you have proven to work
114 points by simonw
114 points by simonw
Nah, your job is to provide code at the speed and level of confidence demanded by your employer consistent with your ethical and legal obligations. If they want to move fast and break stuff on a social media site they don’t need it to be provably completely correct.
Too cynical ... do that for too many years, and it changes YOU
A better bet is to change jobs if you find yourself in that situation, i.e. where you can't do work you're proud of
I don't disagree with your advice, but I think it's worth pointing out just what a privilege it is to even have access to work that you're proud of. In the last 15 years or so I've seen maybe half a dozen ads for jobs worth doing in my line of work in my area. Last time I've held a local one was like ten years ago. I pretty much had to change fields entirely in order to be able to work remotely on challenging projects, and even that is something a lot of people can't risk, and that I could only do because of a very fortunate combo of factors (supportive family, financial cushion and no financial obligations, and many others). Sometimes a cynical take is just gratuitously mean, but sometimes it's just all someone has access to.
Yeah definitely, I think sometimes you have to work with a bad situation, and you need a YEARS-long plan to get out of it. To find better work
The plan could be building the technical skills for another job, which can take years. Or it could be building social connections, etc.
What I argue STRONGLY against is making it a habit to write crappy code (or doing the bare minimum that is incentivized). Then you've actually atrophied your own skills.
Just like I say about LLMs -- you can use them in the "recommended" way, which may atrophy your skills (pumping out crappy code without understanding it).
Or you can use them to build your own skills. If you can build more things, then that increases your value in the job market. [1]
Also, a VERY common situation is:
Do you want to be known as the person who does the bare minimum? Maybe you can impress another high quality person. (I have done this not with work projects, but with side projects done AT WORK)
At every company there are a few people doing good work, even if the company itself is dysfunctional. And those talented people might tap you for a better opportunity
i.e. Putting out apathy and cynicism puts YOU at a disadvantage
[1] Also, ironically, LLMs make testing more important. I strongly agree that
Testing and benchmarking should be high status work
from https://www.broune.com/blog/testing-and-benchmarking-of-ai-compilers
which I posted 9 days ago: https://lobste.rs/s/02ok6n/testing_benchmarking_ai_compilers
This is say a big reason why I work on shell -- because testing and benchmarking lead to better software -- https://oils.pub/release/0.37.0/quality.html
If you think "well I just like to code", then maybe you aren't delivering the value that you think you are. Maybe you're just delivering a bunch of stuff that OTHER people have to test (ironically, similar to bad usage of LLMs)
While I do agree with that sentiment in general, I am not sure it's necessarily good or realistic advice.
Finding a job one is proud of is easier said then done. Pretty sure Mozilla was once such a place. But that changed. Pretty sure many jobs look like that from the outside, not the inside.
And I'd expect that many people start companies with that attitude, only to realize that either they do consulting for companies not having that goal or create products and drown in business, marketing, etc.
All of that usually at varying degrees of financial "loss" only to realize that maybe you should have just done that bad job and used the additional money to have a lot more time outside of the job for things that you can actually be proud of.
A lot of work people are justifiably proud of is approximating the impossible close enough, or beating the external constraints at the cost of some trade-offs. As in «I know it doesn't always work, but it is much better to have it than not»
I don't think it's cynical. Sacrificing accuracy for efficiency is a real engineering trade off.
“Code that works” has to be understood as “good enough for your employers purposes and your own self-respect (while not violating moral rules).”
I don’t think nitpicking like this on a useful post like this is particularly helpful.
Because the article cheerfully espouses the use of a bunch of tools and processes that people find deeply unethical, it's not unreasonable to cast a response that reintroduces that part of what it means to be an engineer.
Actually, we do have an ethical obligation to withhold labor from Facebook.
I always wonder about what type of person would willingly go to work at Facebook at this point in time. Is it just for the CV?
Same could be said for Google, Apple and especially Amazon. Given how many people I've seen in completely unrelated positions and sometimes with severe lack of competence my bet would be: Yes, it's just for the CV.
I got my leg up working at Facebook at a time around the time they were buying Whatsapp, when you could argue that it was already doing some pretty bad stuff. Having a company like that on your resume at that time did wonders in moving you past the screening phases of a hiring pipeline. But I wouldn't say that was most of the value I got out of it. Getting access to their campus and their internal conversation is like falling down the rabbit hole to wonderland. There's so much you could learn from all the engineering and politics going on around you, it's completely overwhelming. I wish everyone could have a chance like that to pull back the curtain and see what these companies are like on the inside -- less like a mythical dragon and more like an incredibly busy ant colony.
But that value of everything you can learn there mostly starts to be realized for society when you cast off the golden handcuffs, take your skills and knowledge, and move on.
If you think AI is going to be a world changing technology Meta is the only place open sourcing their models. Also a lot of the hate for them is because of people discovering things like their uncle being racist and deciding the platform did it to them rather than just making it more obvious.
Meta seem to have given up on open sourcing their models - for LLMs at least. Their last Llama release was Llama 4 back in April.
The Chinese AI labs have been releasing open source (not even just open weight, they actually use OSI licenses for most of theirs) through out 2025 and they are genuinely fantastic. Qwen, DeepSeek, Z.ai, Kimi and more.
Mistral out of France also have some good open weight models, and the OpenAI gpt-oss models are solid too.
They recently open sourced other model types, e.g. https://github.com/facebookresearch/sam-audio
a lot of the hate for them is because of people discovering things like their uncle being racist
That's quite insensitive & uneducated.
The first thing that came to mind is profiting off violence that lead to genocide and undoing the preventative policies in 2025.
And the dedicated Wikipedia article on criticisms of Facebook has plenty more.
It's not uneducated to disagree with you. Amnesty has done a lot to discredit themselves over the years but even taken at face value their objection is that Facebook was not active enough in recruiting translators so that they could more actively engage in censorship, and the algorithm shows people content similar to content they have previously liked. This gets spun hyperbolically as spreading evil even though people had to actively express interest in genocidal content and spread rumors and fear monger as has been tradition for long before Facebook existed. Facebook not censoring is frought but so is asking them to censor. You don't really want Facebook deciding what you're allowed to read.
You'll notice all the big tech companies capitulated to Trump, because the alternative was corporate suicide. He could very easily sign orders or make announcements that could overnight destroy any of them. I don't usually judge people by what they do when they're under duress. At the same time, this change has not seemed to trigger a surge in new genocides, probably because in practice this kind of censorship is always ineffective because people just learn to dog whistle / circumlocute. There is no number of translators they could hire or training that they could give them that would actually be effective, and that would be true for any sufficiently popular online discussion medium. If it wasn't Facebook it would just be something else.
You're free to have a different opinion, but reducing differing opinions to "disliking racist uncle" is dishonest and seems uneducated given the load of BS FB is up to.
Most of it is downstream of people being upset about things they've seen other people say on the service though, that creates the anger and then people come up with grand justifications on shaky foundations. It's a service so you can keep tabs on your highschool crushes and people want to blame it for genocide!
Meta is the only place open sourcing their models
What about Hugging Face?
their uncle being racist and deciding the platform did it to them
I doubt people here hate Facebook for such silly reasons.
Hugging Face isn't competitive with any of the top models, so I'm not counting them. Meta is the only player with major compute and plausible in house expertise that has opened models.
Do not mistake the map for the territory. Remember, Lobsters and Hacker News does not reflect the entirety of IT.
"Move fast and break things" is an old Facebook slogan summarizing their approach to engineering and reliability. "move fast and break stuff on a social media site" is a reference to Facebook specifically. My point is merely that we cannot simultaneously uphold standard "ethical and legal obligations" and contribute labor to Facebook.
If you look at scaling the approaches and economic considerations, the moral framework that has a chance to bring a change via employee attitude is «it is fine to work for Facebook as long as you intentionally write outage-risk-ridden code as much as you can get away with».
As people say, all machines come with two manuals: one that describes what the machine is supposed to do, and one that describes what it actually does.
Yours is a good description of the latter, but both manuals are equally important as one gives meaning and structure to the other.
So, to provide some balance: https://www.youtube.com/watch?v=dVG8W-0p6vg
I think you're responding to the title alone, not the article's topic—engineers shirking the responsibility to review the code they generate with AI before asking others to review it. Though it is hard to call that fully off topic when the title is part of the content.
I read this as something of an apologia for the use of LLMs on the basis that engineering effort should shift to testing. And I do mostly agree with that. However, when writing the code manually we didn’t necessarily prove that it worked in all cases.
In particular, LLMs open up workflows that were often impractical before like "use loads of different testing and qa tools", but also "throw together a bunch of crap very very quickly then rewrite it once you know what you want and what the pitfalls are".
And, side note: there’s less excuse for academics to ship totally crap code now.
And, side note: there’s less excuse for academics to ship totally crap code now.
Well, caring exclusively whether the implemented algorithm matches the (presumably novel) approach as described is not exactly the best match for LLM code…
As one solid book puts it, "software engineering is programming integrated over time". It's easy to get code that's working – that's programming, it works now, at this point in time. It's the "integrated over time" part that's hard in software engineering – making sure it delivers value through its expected lifetime.
I understand that this part isn't the main point the article is making, but I do feel that it's important to address that even if you've proven that this LLM-generated code works, it's not enough, unless the expected lifetime is very short.
This, 100 times.
I've seen heavily-LLM-driven codebases that were huge piles of unnecessary abstractions. The code did work, but when my turn came to need to make some changes, that was no fun!
Maybe this is not as much of a problem for PRs on existing codebases, as the LLM can imitate the existing code. But when they're (ab)used for greenfield projects, this is a real issue.
I think our code needs to be not simply working, but also concise, maintainable, idiomatic, and -- dare I say, whenever possible -- beautiful!
…the junior engineer, empowered by some class of LLM tool, who deposits giant, untested PRs on their coworkers—or open source maintainers—and expects the “code review” process to handle the rest.
It's not just the juniors. The immature, perhaps.
This needs to be spoken about more. It's always a finger pointed at "the juniors" because senior engineers and management tend to be the ones in the debate. But I have personally seen engineers who I highly respect churn out large amounts of LLM garbage that does not match their previous quality at all.
In the last year I have seen two developers with a total of 55 years of experience between them both utter something along the lines of ‘that’s what [LLM du jour] output!’ as though that were a justification.
No, you committed it. I don’t care if you used a tab-completion, and LLM or frankly if you hired a contractor (our mutual employer probably cares about that last one, but I don’t): you committed it and you are responsible for it
Yeah, that's the way. I say the same about documentation. If an LLM helps you with the prose that's great, but the information needs to be organized for reading and scanning. Don't explain the same thing twice. Don't explain fundamentals the audience is expected to know or look up. Focus on signal over noise; don't drown the reader in emoji. Test that your links go to real, relevant pages.
…the junior engineer, empowered by some class of LLM tool, who deposits giant, untested PRs on their coworkers—or open source maintainers—and expects the “code review” process to handle the rest.
It's not just the juniors. The immature, perhaps.
I was involved in a situation where a peer, a very good engineer and someone I trusted, used a LLM tool to write a clean-up script and included it in a last minute larger PR for weekend work (ugh...). The script missed a fairly large edge case and it did a bit of damage before we stopped it. During the scramble to repair the damage the same engineer quickly used an LLM to write the fix but this time mentioned its origin. We gave it much harder scrutiny and found multiple bugs in that. In hindsight, the bug in the first script was obvious but let's look at the larger context: it was their area of expertise, they were senior, well-trusted, and we're understaffed, human, fatigued and working on the weekend. We're also measured on how often we use AI's, an order coming down from C-levels. A perfect set up for failure without the LLM crap.
Can you tell the people responsible for the performance review process at my employer? They seem to think my job is to maximize cursor requests and lines of code
I agree with the cynicism here. I do think that in the current day and age quality simply isn't the thing "making money".
It's marketing, sales, creating the feeling of having made the right choice with a product. This can very much be seen with how very big companies play with that. The big three cloud providers, Microsoft also in the office space, Fortinet, etc. all of them having overpriced and sometimes severely inferior products to competitors, but it feels right to people and managers to use the big player's product and their sales and marketing personal is trained to emphasize these things. This includes Microsoft employees telling people that "You'd easily get hacked" if you'd not take their products and such.
Products largely aren't bought for actual reality. Sure you can leave a bad review, but at this point they already have your money and in most situations people won't change their mind. See Microsoft Teams. I don't know anyone who honestly thinks it's good compared to pretty much anything, yet it is almost standard these days. Same with Outlook, etc. And you cannot even use other arguments such as cost, because it's also not a cheap option.
What's more all the classical arguments like "everyone runs windows" barely count anymore, because everyone runs browsers anyways.
In such a setting the thing that will sell your product simply isn't good engineering. And that's just one area. If you look into other areas, even marketing itself. If you ever took an actual look at companies like Braze (just picking a random company that comes to mind) you'll notice it absolutely reeks of severe incompetence, yet somehow they are on top.
All of this strongly suggests that quality isn't something that's worth aiming for on the business side.
Also just to be clear: Pretty sure each and every of these companies have excellent people working there and somewhere in there I am sure that they even manage to do some great engineering. These are huge companies so general statements about the people working there are not really possible. However, their products and what a customer sees and uses isn't (just) done by these engineers. The fact that some infrastructure or some micro service, or algorithm, etc. is excellent doesn't make a huge company or their product good.
I think all of them, but at least some of them have departments that give you the opportunity to focus on great engineering. Facebook, Microsoft and Google did or still do have those. I heard the same about Amazon.
Still doesn't make proper engineering a priority. And it's hard to even blame the companies for that because again, they are businesses. The right course of action and (sadly) the obligation is to "make money", pretty much no matter what. Safe of breaking the law - if it's too expensive, which in many cases it isn't.
That's not to justify, but to try to understand why it is that way. Would be nice if it could be different, but short of huge catastrophes caused by these actions I do not know how this will change.
And completely layman here, but looks like not even for companies building aircraft proper engineering is an absolute priority, given what can be heard and seen. Sure, they might have good processes overall, but the fact businesses decide to borderline break the law or at least try to find loopholes to get around them without technically breaking them is scary.
All of that can be "justified" in various degrees, but I think when one is honest to oneself from a business perspective good engineering doesn't seem to be worth striving for, above a degree where it increases profit margins, which compared to other areas (marketing, sales, etc.) it sadly does very little. At least not for bigger companies. I think for smaller ones it depends, but that might just be wishful thinking.
This addresses the “untested” part of the problem, but not the “giant PRs,” part. More code always takes more effort to review, regardless of if the automated tests pass.
I see huge PRs as a different issue. I think they're almost always bad, but occasionally they have a place - for a major refactoring that's already been discussed with the other maintainers, and ideally a PR that has dozens of smaller, easier to understand commits.
I'd have said that my faith an author knows their code works is lower when a PR is huge (except trivial cases like machine generated refactorings in a language where those can be proven safe), so it seems like something of the same issue.
This is why I think LLM-assisted development greatly resembles the compiler correctness problem. And, a really compelling pattern to solve that problem with a lot of research behind it is "self-certifying compilation", which basically amounts to automatically generating "proof" along with a generated implementation.
Almost anyone can prompt an LLM to generate a thousand-line patch and submit it for code review. That’s no longer valuable. What’s valuable is contributing code that is proven to work.
The step beyond this that I also view as table stakes is ensuring the code meets team standards, follows existing patterns and conventions, and doesn’t unreasonably accrue technical debt.